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Abstract 


An  introduction  to  the  Structured  Sound  Synthesis  Project  of  the  University  of  Toronto 
is  presented.  The  Structured  Sound  Synthesis  Project  (SSSP)  is  an  interdisciplinary 
project  whose  aim  is  to  conduct  research  into  problems  and  benefits  arising  from  the 
use  of  computers  in  musical  composition.  This  research  can  be  considered  in  terms  of 
two  main  areas;  the  investigation  of  new  representations  of  musical  data  and 
processes,  and  the  study  of  man-machine  communication  as  it  relates  to  music. 
Underlying  goals,  plan  of  research,  and  methodologies  are  discussed.  In  addition, 
results  of  the  first  twelve  months  of  the  project  are  presented,  including  a  v/orking  pro¬ 
totype  of  an  on-line  digital  synthesizer  based  system. 

Integral  to  the  research  described  is  the  evolution  of  a  computerized  environment 
which  one  could  term  a  "composer’s  assistant."  A  basic  premise  of  our  work  is  that  we 
can  enhance  our  understanding  of  the  process  of  music  composition  by  developing 
such  a  facility.  Therefore,  the  development  of  the  system  —  in  combination  with 
observing  the  interaction  between  it  and  trained  composers  --  constitutes  one  of  the 
main  activities  of  our  research.  Key  words  applicable  to  the  project  are:  interactive, 
real-time,  music  (composition  and  synthesis),  mini-computer,  special  digital  sound 
synthesizer,  and  graphics-oriented  command  language. 
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Preface 


This  document  is  the  first  in  a  series  of  technical  documents  to  be  issued  by  the  SSSP. 
The  purpose  of  these  documents  is  to  facilitate  access  to  information  concerning  the 
activities  and  interim  results  of  the  project.  Because  this  is  the  first  report,  it  is  broad 
rather  than  deep,  and  is  intended  to  provide  the  background  with  which  to  understand 
and  interpret  the  more  specific  documents  that  will  follow.  Because  it  presents  —  in 
many  cases  --  interim  results,  comments,  criticisms,  or  einy  other  type  of  feedback  is 
solicited. 

The  research  described  in  this  paper  has  been  funded  by  the  Canada  Council  Humemi- 
ties  and  Social  Sciences  Division  grant  number  S76-0099.  This  support  is  gratefully 
acknowledged.  The  current  document  is  based  on  a  recent  grant  renewal  application 
to  the  Canada  Council.  The  project  is  administrated  by,  and  located  in,  the 
Systems  Research  Group  of  the  Departments  of  Computer  Science  and 
Engineering  at  the  University  of  Toronto.  The  research  is  carried  out  with 
co-operation  of  the  Faculty  of  Music  of  the  University  of  Toronto, 


Computer 
Electrical 
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1.  Scope  and  Objectives  of  Study 


The  objective  of  the  current  project  is  to  conduct  research  into  problems  and  benefits 
arising  from  the  use  of  computers  in  musical  composition.  A  study  in  this  field  is  inter¬ 
disciplinary  by  nature.  The  scope  of  the  current  project  involves  three  main  discip¬ 
lines:  music  (composition  and  theory),  computer  science,  and  electrical  engineering. 
Each  member  of  the  research  team  is  knowledgable  in  more  than  one  of  these  areas, 
and  all  have  a  history  of  research  in  the  use  of  technology  in  the  humanities. 

The  musical  problem  with  which  this  project  is  concerned  is  our  current  lack  of  under¬ 
standing  of  the  process  of  musical  composition.  That  is,  while  there  exist  theories 
which  deal  with  the  artifacts  of  this  process  (the  study  of  scores,  performance,  etc.) 
and  resulting  esthetic  questions,  our  ability  to  explicate  the  strategies  and  decision 
making  employed  in  composition  is  very  limited.  Our  lack  of  knowledge  in  this  domain 
was  perhaps  best  brought  out  when  resarchers  began  attempting  to  provide  computer¬ 
ized  tools  to  aid  the  composer  in  this  process.  In  short,  such  attempts  have  met  with 
with  only  limited  success.  That  this  is  in  fact  the  case  can  be  illustrated  by  contrasting 
the  relatively  small  amount  of  music  which  has  been  written  using  such  facilities 
(Melby,  1976)  with  the  amount  of  research  which  has  gone  into  their  development  (Bat¬ 
tier  and  Arveiller,  1976).  However,  just  as  attempts  to  develop  such  facilities  have 
served  to  point  out  the  problems,  they  also  serve  --  in  our  opinion  —  as  ideal  environ¬ 
ments  for  filling  in  some  of  the  current  gaps  in  our  knowledge.  Towards  this  end, 
therefore,  it  is  our  musical  objective  is  to  investigate  musical  composition  with  the  aim 
of  developing  better  representations  of  the  processes  and  data  involved. 

As  stated  in  section  4:  Research  Plan  and  Methods,  a  key  aspect  in  carrying  out  the 
above  is  the  establishment  of  a  computerized  environment  which  would  evolve  to  the 
point  where  it  could  be  considered  a  "composer’s  assistant."  The  purposes  in  so  doing 
are  twofold.  In  the  first  place,  the  main  vehicle  for  collecting  information  is  provided 
through  observation  of  the  interaction  of  trained  composers  with  the  system. 
Secondly,  such  a  system  serves  as  a  tool  which  enables  the  testing  of  interim  results  of 
the  research. 

Given,  therefore,  that  the  hoped  for  success  of  the  project  is  based  largely  upon  the 
interaction  of  both  musicians  and  technologists  with  the  proposed  system,  it  can  be 
seen  why  the  man-machine  communication  problem  constitutes  the  second  main 
objective  of  the  research.  In  the  realm  of  computer  science  this  problem  centers  on 
two  main  areas:  the  efficient  internal  representation  of  data  and  processes,  and  the 
establishment  of  a  suitable  task-oriented  command  language  for  accessing  them.  To 
enable  the  above,  true  interaction  and  immediate  turn-around  are  essential.  Providing 
the  hardware  facilities  to  meet  these  demands  is  seen  as  the  prime  engineering  prob¬ 
lem.  Towards  these  ends,  the  first  phase  of  our  work  has  seen  the  development  of  a 
special-purpose,  computer-controlled  digital  sound  synthesizer,  along  with  appropriate 
software.  (See  section  5:  Work  Completed  and  in  Progress.)  The  main  thrust  of  the  next 
phase  of  the  project  is  to  make  the  potential  of  these  developments  accessible  to  the 
composer.  That  is,  we  hope  to  demonstrate  the  possibilities  of  a  man-machine  environ¬ 
ment  in  which  the  composer  can  more  fully  exploit  the  creative  potential  of  the 
medium  and  create  works  of  musical  significance.  Success  in  doing  so  will  not  only 
demonstrate  an  understanding  of  the  underlying  musical  problems,  but  have  important 
implications  concerning  the  use  of  computers  in  humanistic  endeavour. 
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2.  Theoretical  Significance  and  Practical  Importance 

The  theoretical  and  practical  significance  of  the  current  project  can  be  discussed  in 
terms  of  its  direct  and  indirect  consequences,  and  potential  "spin-off"  research. 

The  main  music-theoretical  significance  of  the  research  has  to  do  with  the  conceptuali¬ 
zation  of  musical  process  which  it  implies.  Traditionally,  much  of  music  theory  has 
deadt  with  studies  of  musical  artifacts  such  as  scores.  Such  an  approach  could  be 
viewed  as  being  analogous  to  the  study  of  stylistics,  as  in  literature  and,  therefore, 
sheds  little  light  on  our  main  interest:  the  compositional  process.  The  current  project 
deals  with  music  as  an  active  process,  as  is  manifest  in  the  performance  of  musical 
tasks  (such  as  composition):  furthermore,  it  is  our  hypothesis  that  this  process  is 
observable,  given  a  suitable  environment  and  methodology.  By  exploiting  current  tech¬ 
nological  means  in  an  effort  to  enable  such  observation,  it  is  hoped  that  significant 
insights  into  such  musical  processes  will  be  gained. 

In  terms  of  the  practical  significance  of  such  a  project,  it  is  clear  that  should  it  be  suc¬ 
cessful,  the  results  of  our  effort  will  provide  a  valuable  tool  for  the  contemporary  com¬ 
poser.  The  system  will  not  only  provide  the  musician  with  an  environment  for  compos¬ 
ing  the  music,  but  in  addition  will  enable  him  to  perform  it  (where  performing  is  analo¬ 
gous  to  conducting)  —  either  solo  or  in  conjunction  with  conventional  musical  instru¬ 
ments.  Such  a  facility  would  help  resolve  the  current  dead-lock  in  music  illustrated  on 
the  one  hand  by  the  interest  of  composers  in  electoacoustic  music,  and  on  the  other, 
by  their  frustration  with  the  current  means  available.  The  work  also  could  have  strong 
implications  in  other  areas  of  music,  such  as  music  education  and  the  psychology  of 
musical  perception. 

From  a  broader  point  of  view,  the  research  proposed  has  significant  importance  as  a 
demonstration  of  the  ability  of  artists  to  utilize  advanced  technology  in  non-trivial 
humanistic  endeavour.  In  a  society  whose  members  too  often  feel  dominated  rather 
than  served  creatively  by  high  technology,  the  artistic,  esthetic,  sociological  and  tech¬ 
nological  importance  of  the  proposed  work  cannot  be  ignored. 

Finally,  after  the  hoped  for  success  of  the  project,  several  further  research  areas  are 
suggested.  These  include  exploring  relationships  between  music  and  visual  images, 
human  information  processing  research,  and  psycho-acoustics.  There  is  a  precedent 
for  such  research  in  Canada  in  the  work  of  Gabura  and  Ciamaga  (1968),  Pulfer  (1970), 
and  Truax  (1973).  It  is  the  intention  of  the  Structured  Sound  Synthesis  Project  to 
advance  such  research  beyond  the  current  state  of  the  art. 


3.  Relationship  to  Existing  Research  and  Literature 


3.1.  General 

Two  recent  publications  give  a  general  survey  of  the  literature.  These  are  Buxton 
(1977a)  and  Buxton  (1977b).  The  latter  represents  a  compilation  of  questionaires  cir¬ 
culated  among  researchers  and  musicians  active  in  the  field.  This  work  was  supported 
by  the  Canadian  Commission  for  Unesco.  In  the  section  to  follow,  we  will  discuss  those 
aspects  of  the  literature  which  relate  specifically  to  the  research  of  the  SSSP. 
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We  will  begin  by  presenting  various  criteria,  on  which  to  base  our  discussion.  To  begin 
with,  material  will  be  presented  in  terms  of  two  main  application  areas:  the  use  of  the 
computer  in  the  compositional  process,  and  the  generation  of  acoustical  signals.  The 
reader  should  be  aware,  however,  of  the  bias  implicit  in  this  separation  of  abstract 
musiced  structures  on  the  one  hand,  and  sound  on  the  other.  This  is  a  bias  which  is  nei¬ 
ther  reflected  in  all  of  the  literature,  nor  is  entirely  justifiable  in  terms  of  music 
theory.  Keeping  these  misgivings  in  mind,  we  use  this  approach  for  ease  of  presenta¬ 
tion. 

In  addition  to  the  above  mentioned  separation  of  topics,  we  will  orient  our  presentation 
around  three  central  questions: 

1)  What  is  the  theoretical  basis  or  ''model''  on  which  the  system  is  founded 

(implicitly  or  explicitly),  and  what  are  the  resulting  musical  assump¬ 
tions  or  restrictions  imposed  on  the  user? 

2)  What  is  the  hardware  configuration  on  which  the  system  is  implemented; 

that  is,  what  equipment  is  used  and  how  is  it  set  up? 

3)  What  is  the  mode  of  man-machine  communication;  that  is,  how  do  the 

composer  and  the  system  interact? 

While  these  criteria  are  neither  mutually  exclusive  nor  all  encompassing,  they  do  pro¬ 
vide  a  basis  for  comparison  among  systems  of  interest. 


3.2.  Computers  in  Music  Composition 

Computer  systems  for  music  composition  can,  for  ease  of  discussion,  be  considered  in 
terms  of  two  categories  of  functions:  those  which  take  an  active  role  in  the  composi¬ 
tional  process  —  that  is,  take  part  in  musical  decision  making,  generate  notes,  etc.  -- 
and  those  which  are  more  passive,  for  example,  those  which  aid  the  composer  through 
the  provision  of  an  efficient  editor  or  notational  scheme.  Let  us,  somewhat  arbitrarily, 
term  these  "generative"  and  "deterministic"  functions,  respectively. [ l]  Examples  of 
systems  in  which  generative  functions  play  a  large  role  are;  MUSICOMP  (Hiller  and 
Isaacson,  1959),  the  ST  programs  of  Xenakis  (Xenakis,  1971),  PROJECT  2  (Koenig,  1970), 
and  POD  (Truax,  1973;  Buxton,  1975).  In  each  of  these  systems,  the  important  point  to 
be  noted  is  that  in  order  to  be  implemented,  each  demanded  that  the  author  first  for¬ 
malize,  and  then  program  the  "rules"  of  a  particular  theory  of  composition.  This  gives 
rise  to  certain  questions.  The  prime  one  is  this:  given  that  decision  making  is  under¬ 
taken  by  the  program,  to  what  extent  do  we  posess  sufficient  knowledge  of  the  musical 
processes  involved  to  program  the  knowledge  base  on  which  these  decisions  are  made? 
Each  of  the  projects  mentioned  represents  an  attempt  to  deal  with  this  problem. 
These  efforts  have  brought  to  light  several  previous  misconceptions  concerning  music, 
just  as  attempts  at  automated  speech  translation  did  in  linguistics.  The  central  prob¬ 
lem  has  been  the  inadequacy  of  traditional  music  theory  to  explicate  the  musical 
processes  involved.  That  is  to  say,  we  are  severely  limited  in  our  current  ability  to 

[l]  Note  that  both  types  of  functions  are  commonly  found  in  one  system:  POD  (Truax, 
1973),  for  example.  We  choose  to  make  the  distinction,  however,  due  to  their 
differing  music-theoretical  implications. 
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establish  a  knowledge  base  for  computerized  musical  decision  making. 

The  above  discussion  presents  a  context  in  which  two  important  aspects  of  the  SSSP 
can  be  seen.  First,  the  intention  is  not  to  put  together  yet  another  compositional  sys¬ 
tem  of  the  generative  type;  the  requisite  understanding  of  the  underlying  musical 
processes  is  lacking.  Consequently,  our  goal  is  to  undertake  a  program  of  research 
which  will  make  some  contribution  to  filling  this  gap  in  our  music-theoretical 
knowledge.  Our  approach  in  doing  so  involves  the  study  of  what  we  have  called  "deter¬ 
ministic"  functions,  to  which  we  will  now  turn  our  attention. 

What  we  call  "deterministic"  systems  are  generally  characterized  as  providing  a  user 
with  a  set  of  commands  or  operators  felt  to  be  appropriate  to  carry  out  a  particular 
task.  What  distinguishes  such  systems  from  those  described  above  is  the  fact  that  the 
commands  are  not  "generative"  functions;  that  is,  all  decision  making  remains  with  the 
user.  Use  of  these  systems  generally  takes  the  form  of  the  user  calling  a  sequence  of 
commands  in  such  an  order  to  realize  a  particular  musical  goal.  Intelligent  use  of  such 
a  system,  therefore,  is  only  possible  when  the  composer  has  sufficient  knowledge  of  the 
various  options  to  (a)  define  a  realizable  goal,  and  (b)  to  be  able  to  plan  a  strategy  — 
i.e.  sequence  of  commands  —  enabling  him  to  realize  that  goal.  As  good  examples  of 
such  systems  we  cite  the  NRC  system  (Pulfer,  1970),  and  the  system  of  the  Experimen¬ 
tal  Music  Studio  at  MIT  (Vercoe,  1975).  Clearly,  the  strength  of  such  a  system  depends 
on  the  designer  understanding  the  problem  domain  sufficiently  to  be  able  to  provide  an 
appropriate  command  structure  for  the  task  at  hand.  He  must  reduce  the  global  prob¬ 
lem  into  sub-tasks,  each  with  its  own  operators,  and  then  provide  an  interface  among 
these  sub-systems;  all  of  which  --  to  be  successful  —  must  reflect  the  cognitive  struc¬ 
tures  of  the  user.  It  is  in  this  aspect  of  task  analysis  —  to  which  the  two  systems  men¬ 
tioned  owe  their  success  —  that  our  main  interest  lies.  Much  of  our  approach  derives 
from  the  thesis  of  the  theorist  Otto  Laske  (1975  and  1977).  This  is  that  since  the  imple¬ 
mentation  of  such  systems  represent  the  results  of  task  analysis,  it  therefore  reflects 
the  current  understanding  of  the  problem  domain  and  can  justifiably  be  considered  an 
explicit  model  or  theory  of  that  problem  space.  Therefore,  as  will  be  seen  in  section  4 
of  this  paper  (Research  Plan  and  Methods),  much  of  our  interest  is  in  making  such  a 
task  analysis  of  musical  composition,  and  testing  the  results  through  implementation 
in  an  appropriate  interactive  environment. 

The  main  drawback  of  many  "deterministic"  systems  is  that  they  have  restricted  the 
composer  to  working  in  a  note-by-note  manner,  a  bias  which  does  not  generally  reflect 
a  composers  conceptualization  of  a  work  in  progress.  The  POD  system  of  Truax  was  an 
attempt  to  get  away  from  this  problem  by  enabling  the  composer  to  work  with  groups 
of  sounds,  rather  than  single  sound  events.  While  a  useful  step,  this  approach  then 
imposed  the  use  of  stochastic  "generative"  type  functions  —  the  problems  with  which 
have  already  been  mentioned  —  on  the  user.  The  fundamental  factor  which  we  feel  is 
neglected  in  each  of  these  systems  is  an  adequate  consideration  of  musical  composi¬ 
tions  as  hierarchic  structures.  While  much  music  analysis  (Winnograd,  1968;  Smoliar, 
1971)  has  exploited  the  hierarchic  nature  of  music,  very  few  compositional  systems 
have  provided  the  composer  %vith  the  tools  to  enable  him  to  construct  compositions 
according  to  an  arbitrary  "deep  structure"  (Chomsky,  1972).  Clearly,  if  the  composer 
was  provided  this  facility,  and  in  addition  provided  operators  (such  as  perform,  invert, 
etc.  )  which  could  act  upon  any  sub-structure  in  the  hierarchy,  he  would  gain  the 
advantages  of  what  Truax  was  attempting,  while  avoiding  many  of  the  problems.  We  are 
not  so  naive  as  to  believe  that  such  an  approach  would  be  free  of  bias  in  some  other 
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direction;  however,  it  is  the  orientation  of  this  new  bias  which  is  one  of  the  most 
interesting  aspects  of  investigation. 

One  thing  is  clear  from  the  work  of  Truax,  Vercoe,  and  Mathews  and  Moore  (1970):  that 
the  amount  and  rate  of  learning  which  takes  place  using  a  compositional  system  is 
directly  related  to  the  degree  of  interaction  that  the  system  provides.  Since  aural 
feedback  is  an  integral  part  of  an  interactive  system  for  music  composition  [2],  we  will 
now,  therefore,  turn  our  attention  to  the  sound  generating  aspect  of  computer  music. 


3.3.  SouTid  Synthesis  with  Computer 

In  light  of  the  above  discussion,  it  can  be  seen  that  in  terms  of  sound  synthesis  our 
prime  concern  is  in  providing  the  composer  access  to  a  musically  interesting  palette  of 
timbres  within  the  contejrt,  of  an  interactive  system  for  music  composition  and  perfor¬ 
mance.  The  key  words  here  are  "access,"  "musically  interesting"  and  "interactive." 
"Access"  is  meant  in  a  cognitive,  physical,  and  economic  sense.  By  "musically  interest¬ 
ing,"  we  imply  that  the  sounds  must  have  time-varying  spectra,  comparable  in  com¬ 
plexity  to  sounds  found  in  nature.  Finally,  the  demand  for  an  interactive  system 
implies  that  these  complex  sounds  must  be  able  to  be  generated  in  real  or  close  to 
real-time.  The  number  of  options  available  which  meet  the  demands  of  these  criteria 
are  limited.  Our  purpose  now  is  to  justify  our  own  approach  in  terms  of  those 
described  in  the  literature. 

The  result  of  the  combined  demand  for  complexity  and  interaction  precludes  our  using 
classical  digital  synthesis,  as  described  in  Mathews  (1969).  While  this  technique  has 
proven  excellent  for  sonic  research,  we  feel  that  we  cannot  provide  adequate  sound 
quality/complexity  while  maintaining  a  high  enough  degree  of  interaction.  An  alterna¬ 
tive  approach  would  have  been  to  utilize  a  "hybrid"  system,  in  which  analogue  sound 
processing  equipment  (such  as  a  Moog  synthesizer)  is  controlled  by  a  mini-computer 
(Mathews  and  Moore,  1970);  however,  our  experience  with  analogue  equipment  (Vink 
and  Buxton,  1974)  and  its  use  in  hybrid  systems  (Gabura  and  Ciamaga,  1968)  has  con¬ 
vinced  us  that  this  approach  is  neither  flexible  enough,  nor  does  it  provide  adequate 
standards  of  precision  and  stability.  We  chose,  therefore,  to  take  the  approach  of  a 
"mixed-digital"  system,  along  the  lines  of  that  described  in  Alonso  et  al.  (1976).  This 
approach  —  which  involves  a  computer-controlled  digital  sound  s>mthesizer  —  allows 
suitably  complex  sounds  to  be  generated,  in  real-time,  with  low  computational  over¬ 
head  in  a  small,  economical  system.  If,  in  contrast  to  a  digital  system  of  the  MUSIC  V 
type,  one  takes  advantage  in  the  system’s  design  of  the  recent  work  of  Chowning  (1973) 
and  Kaegi  (1973,  74),  the  apparent  limitations  to  generality  can  be  minimized.  Furth¬ 
ermore,  these  limitations  are  seen  as  acceptable  when  one  recalls  that  our  concern  is 
not  to  enable  the  synthesis  of  "any"  sound;  rather,  to  provide  the  composer  with  an 
adequate  timberal  palette.  This  simply  reflects  the  fact  that  we  are  far  more 
interested  in  the  relationships  among  sounds  in  some  musical  context,  than  in  the 


[2]  Some  theorists  would  dispute  this  fact,  arguing  that  traditionally  composers  have 
never  had  such  aural  feed-back,  so  why  should  they  need  it  now?  We  feel,  howev¬ 
er,  that  the  composer  of  conventional  music  does  have  such  feed-back  —  in  his 
mind’s  ear  —  enabled  by  his  familiarity  with  the  long  tradition  of  western  music; 
a  tradition  that  does  not  exist  for  the  sonic  materials  available  to  the  contem¬ 
porary  composer. 
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intrinsic  quality  of  any  particular  sound  in  isolation. 

Finally,  we  feel  that  one  of  the  impediments  to  the  acceptance  and  understanding  of 
music  produced  with  the  aid  of  technology  is  the  limited  means  by  which  such  music 
can  be  presented  in  public.  Current  limitations  on  the  possibilities  for  live  perfor¬ 
mance  and  the  inadequacies  of  the  tape  medium  make  it  difficult  for  a  composer  to 
realistically  evaluate  the  success  of  a  composition  in  the  context  of  a  concert  situation. 
Since  we  adhere  to  the  belief  that  a  work  is  not  completed  (does  not  exist?)  until  it  is 
performed,  we  feel  that  we  cannot  ignore  this  problem  in  our  research.  In  this  regard, 
we  have  taken  an  approach  similar  to  Martirano  (Franco,  1974)  and  Kobrin  (1975),  in 
including  a  multi-channel  diffusion  system  as  part  of  our  facility.  Furthermore,  our 
research  should  result  in  a  system  which  is  small  enough  to  be  feasibly  transported  to 
a  concert  hall.  The  notion  of  performance  in  this  situation  would  then  be  more  analo¬ 
gous  to  conducting  (such  as  in  the  GROOVE  system  of  Mathews  and  Moore)  than  to 
instrumental  performance.  In  either  case,  the  important  point  is  that  the  composer 
would  have  hitherto  unattainable  --  in  electronic  music  at  least  —  control  over  the 
parameters  of  his  composition  during  a  performance  situation. 


4.  Research  Plan  and  Methods 


4.1.  General 

As  has  been  stated  in  previous  sections,  the  goal  of  this  research  is  to  investigate  the 
process  of  musical  composition.  Our  plan  of  procedure  in  explicating  parts  of  this 
complex  process  is  a  form  of  classical  problem  reduction.  Generally  stated,  our 
methodology  involves  breaking  the  process  down  into  well  defined  sub-tasks,  and  then 
implementing  the  results  in  the  form  of  computer  programs  on  a  suitably  configured 
mini-computer.  Trained  musicians  will  then  be  observed  interacting  with  the  resulting 
system.  Through  this  observation  and  interrogation,  we  will  be  able  to  evaluate  previ¬ 
ous  assumptions,  and  gain  additional  insights  into  the  problem  domain.  Through 
several  iterations  of  this  process  —  when  combined  with  a  man-machine  interface  mak¬ 
ing  the  system  accessible  to  the  composer  —  we  feel  that  considerable  progress  can  be 
made  towards  our  stated  goal. 

Clearly,  the  success  of  the  above  is  contingent  on  many  factors  besides  the  purely 
musical  problems:  a  suitable  hardware  configuration,  a  flexible  programming  environ¬ 
ment,  and  qualified  personnel  (including  an  adequate  body  of  musically  sophisticated 
subjects)  are  all  essential.  Therefore,  besides  giving  details  of  our  approach  to  the 
problem  analysis,  the  remainder  of  this  section  will  attempt  to  demonstrate  our  ability 
to  carry  out  the  program  of  research  described.  In  order  to  place  our  discussion  in 
context,  we  shall  begin  by  describing  the  hardware  environment  in  which  the  work  will 
take  place. 
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4.2.  An  Overview  of  the  SSSP  Hardware 

The  function  of  the  SSSP  hardware  is  to  provide  the  physical  medium  whereby  a  com¬ 
poser  can  interactively  define,  audition,  and  modify  both  single  and  complex  groups  of 
sounds.  In  the  development  of  such  a  tool,  the  two  most  important  design  criteria  are 
high  audio  quality,  and  optimization  of  the  man-machine  interface.  The  tool  is 
intended  to  serve  as  the  basis  of  our  research  into  musical  processes  and  data 
representation,  and  as  a  practical  tool  for  musical  composition  and  performance. 

Given  the  above,  we  can  now  generalize  some  of  our  requirements  of  the  system 
hardware.  These  are  as  follows; 

polyphonic:  the  system  must  be  able  to  generate  several  voices  of  sound  (up  to 
16  in  our  case)  simultaneously. 

complex,  time-varying  spectra:  each  of  the  audio  generators  must  be  capable  of 
producing  sounds  having  a  spectrum  which  is  easily  defined  and  con¬ 
trolled,  which  may  vary  during  the  duration  of  a  sound  (as  dipthongs  in 
speech)  and  whose  complexity  is  comparable  to  sounds  found  in  nature. 

real-time  generation:  the  device  must  be  able  to  generate  such  sound  in  real¬ 
time  in  order  to  enable  the  interactive  specification,  audition,  and 
modification  of  sonic  structures:  that  is  to  say,  to  facilitate  learning. 

several  output  channels:  the  (16)  generator  voices  should  be  able  to  be  grouped 
into  a  number  of  "choirs,"  or  mutually  exclusive  sets  of  voices.  (We  have 
chosen  4.)  Each  of  the  choirs  should  then  be  able  to  be  mixed,  or  distri¬ 
buted  independently  over  a  large  number  (16  in  our  case)  of  discrete 
audio  output  channels.  This  is  to  enable  control  sound  localization  and 
the  simulation  of  moving  sound  sources. 

interface  to  other  instruments:  the  signals  generated  using  the  device  sould  be 
able  to  be  combined,  under  computer  control,  with  analogue  signals  ori¬ 
ginating  from  outside  the  system.  It  is  the  sum  of  these  (up  to  16) 
external  signals,  mixed  with  the  4  choirs  of  the  synthesizer,  which  are 
fed  to  the  channel  distributor. 

compact.'  the  entire  system  should  be  portable  in  the  same  sense  that  a  rock 
band  is.  That  is  to  say,  the  system  should  be  able  to  be  used  in  a  con¬ 
cert  situation  and  not  restricted  to  a  fixed  studio. 

practical:  we  are  trying,  from  the  hardware  point  of  view,  to  pro\ride  a  real  tool 
for  the  real  world.  The  system  must  be  cost  effective,  reliable,  and  cog¬ 
nitively  accessible. 


A  functional  block  diagram  of  such  a  system  is  given  below  in  figure  1.  In  it,  we  see  6 
main  components  (besides  the  user):  the  I/O  transducers,  the  computer,  the  sound 
synthesizer,  the  computer-synthesizer  interface,  the  channel  distributor,  and  the  col¬ 
lection  network.  We  shall  proceed,  therefore,  by  giving  a  brief  description  of  each  of 
these  functional  units.  Since  it  is  the  voice  of  the  system,  we  shall  begin  mth  the 
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synthesizer. 


synthesizer:  the  role  of  the  synthesizer  is  to  take  data  sent  to  it  by  the  com¬ 
puter,  and  accordingly  produce  sounds  which  meet  the  criteria  outlined 
above.  The  device  has  16  oscillators  whose  outputs  can  be  passed  to  the 
channel  distributor  on  one  of  4  possible  busses. 

computer:  in  terms  of  the  specifics  of  the  system,  the  role  of  the  computer  is 
threefold:  control,  translation,  and  memory.  The  control  aspect  is  to 
provide  update  data  to  the  synthesizer,  channel  distributor  and  input 
network,  and  to  monitor  their  status.  The  updated  data  is  specified  by 
the  user  via  the  input  transducers.  Thus,  the  role  of  translation  is  to 
convert  data  from  the  external  representation  of  sound  as  specified  by 
the  user,  to  the  internal  representation  utilized  by  the  machine.  We 
could  expand  on  this  point  to  say  that  the  role  of  such  translation  is  to 
render  the  mechanics  of  sound  synthesis  transparent  to  the  user,  and  to 
enable  sounds  to  be  defined  in  terms  of  the  user’s  application,  not  the 
acoustical  model  employed  by  the  hardware. 

Since  the  purpose  of  the  system  is  to  enable  the  user  to  deal  with  com¬ 
plex  groups  of  sounds  rather  than  merely  single  sound  events,  it  is  clear 
that  all  data  need  not  be  specified  in  real-time.  A  composition  is  gradu¬ 
ally  built  up:  an  iterative  process.  Thus,  we  have  the  data  base  manage¬ 
ment  aspect  of  the  computer’s  function:  in  generating  the  updated 
parameters  for  the  peripheral  devices,  the  computer  must  integrate  all 
of  the  data  currently  specified  by  the  user  including  certain  parame¬ 
ters  which  may  be  controlled  in  real-time  (performance). 

The  computer  selected  for  use  by  the  SSSP  is  of  the  PDP-11  type.  For 
the  initial  system,  we  shall  make  use  of  the  PDP-11/45  computer  of  the 
Dynamic  Graphics  Project  and  the  Data  Base  Management  Group  of  the 
Computer  Systems  Research  Group  of  the  University  of  Toronto.  This 
computer,  funded  by  NRC,  includes  the  graphics  facilities  described 
below,  as  well  as  a  tape  drive,  disk  drives,  and  several  terminals.  The 
system  functions  under  the  UNIX  timesharing  system,  developed  at  Bell 
Telephone  Laboratories. 

interface:  the  interface  module  functions  mainly  as  an  intermediary  between 
the  computer  and  the  synthesizer,  channel  distributor,  and  collection 
network.  Primarily,  the  information  being  distributed  is  control  infor¬ 
mation.  Audio  signals  are  passed  among  devices  via  the  4  analogue 
busses. 

channel  distributor:  the  function  of  this  module  is  to  take  the  4  channels  of 
audio  provided  by  the  synthesizer  and  collection  network,  and  to  distri¬ 
bute  them  independently  over  the  16  discrete  channels  of  output.  Thus, 
we  have  potentially  4  independent  simulated  moving  sound  sources. 

collection  network:  this  module’s  function  is  to  enable  the  synthesized  sounds 
to  be  combined  —  under  computer  control  --  with  sounds  originating 
from  other  sources  (such  as  conventional  musical  instruments).  The 
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device  is  essentiedly  a  16  to  4  channel  mix-down  system  with  four  moni¬ 
tor  speakers  for  the  performers.  It  is  compact  and  of  novel  design. 

Input/Output  Transducers:  the  transducers  for  which  the  system  is  currently 
designed  are:  a  typewriter  type  keyboard,  loudspeakers,  headphones, 
and  a  graphical  input/output  system  (including  a  tablet  and  fast 
vector-drawing  refresh  crt  display). 

With  few  exceptions,  development  work  for  all  of  the  above  described  devices  is  com¬ 
pleted.  The  synthesizer  is  currently  operational  on  the  PDP-11/45,  and  the  distribution 
and  collection  networks  are  demonstrable  in  prototype  form.  These  developments  will 
be  described  in  more  detail  in  section  5:  Work  Completed  and  in  Progress. 


4.3.  Software  Structure:  Considerations  of  Task  Analysis 


4.3.1.  General 

In  this  section,  intentions  for  composer  oriented  software  will  be  detailed.  In  all  of  the 
examples  given,  the  heavy  emphasis  on  graphics  oriented  command  structures  should 
be  noted.  This  is  an  important  aspect  in  our  approach;  one  which  we  feel  is  imperative 
in  order  to  realize  a  well  designed  man-machine  interface.  For  ease  of  presentation  we 
will  consider  the  software  modules  according  to  the  five  categories  listed  below  (of 
which  the  first  3  are  of  the  highest  priority).  These  divisions  constitute  the  first  step  in 
our  task  analysis. 

1  Orchestra  Editors 

2  Score  Editors 

3  Perform  Programs 

4  Channel  Distribution  Editor 

5  Collection  Network  Editor 

Utility  and  system  level  software  will  be  discussed  later  in  section  4,  under  schedule  of 
work  to  be  done. 


4.3.2.  Orchestra  Editor 

If  we  are  going  to  synthesize  sounds,  we  have  an  obvious  interest  in  being  able  to  con¬ 
trol  "timbre":  however,  the  nature  of  "timbre"  for  musical  purposes  is  rather  elusive. 
For  example,  the  American  Standards  Association  states  "Timbre  is  that  attribute  of 
auditory  sensation  in  terms  of  which  a  listener  can  judge  two  sounds  similarly 
presented  and  having  the  same  loudness  and  pitch  are  dissimilar."  Traditional  explana¬ 
tions  (e.g.  Helmholtz)  have  restricted  their  description  to  the  physical  (Adz.  acoustical) 
properties  of  sounds.  Two  things  are  clear,  however:  that  ideally,  timbre  should  be 
described  in  the  perceptual,  rather  than  acoustical  domain;  second,  timbre  is  a  multi¬ 
dimensional  attribute  of  sound,  such  that  the  number  of  dimensions  inhibits  the  under¬ 
standing  and  control  of  the  perceived  phenomenon.  Our  prime  objective,  then,  is  to 
utilize  the  computational  and  graphical  power  available  to  optimize  our  ability  to  con¬ 
trol  this  multi-dimensional  attribute.  The  expected  goal  is  that  experience  gained  from 
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work  initially  at  the  lower  acoustical  level,  will  provide  insights  enabling  us  to  develop  a 
control  mechanism  functioning  on  the  higher  perceptual  level. 

In  our  system  the  closest  analogy  to  the  timbre  of  a  musical  instrument  is  an  "OBJECT" 
(after  Schaeffer,  1966).  By  our  definition,  an  object  is:  "a  named  set  of  attributes  which 
will  result  in  sounds  having  different  pitches,  durations,  and  amplitudes  to  be  perceived 
as  having  the  same  timbre".  In  our  definition,  it  is  significant  that  we  have  stated  noth¬ 
ing  about  the  nature  of  those  attributes  constituting  an  object.  This  is  to  enable  us  to 
use  a  variety  of  modes  or  "representations"  to  define  an  object.  Each  mode  of  descrip¬ 
tion  corresponds  to  a  particular  acoustical  model  used  to  generate  sounds.  Thus,  as 
our  insights  into  timbral  control  develop,  we  are  able  to  refine  our  means  of  object 
specification  to  reflect  the  improved  model.  Therefore,  each  of  the  Orchestra  Editor 
descriptions  outlined  below  reflects  a  different  approach,  or  "model"  to  the  description 
of  musical  "timbre".  Furthermore,  each  should  enable  the  user  to  audition  the  attri¬ 
butes  of  the  object  at  test  frequencies  and  amplitudes  (both  individually  and  in  combi¬ 
nations)  in  order  to  familiarize  himself  with  the  sonic  resources  available.  The  modes 
of  object  speciflcation  described  below  generally  reflect  the  different  modes  of  sound 
synthesis  possible  with  the  digital  synthesizer,  as  described  in  section  5;  Work  Com¬ 
pleted  and  in  Progress. 


4.3.2. 1.  Fixed  Waveform 

Fixed  waveform  is  the  simplest  method  of  sound  specification.  Using  this  mode,  the 
user  need  only  be  provided  the  tools  to  enable  him  to  audition  sounds  having  different 
fixed  waveforms  (which  he  may  define  himself).  He  should  be  able  to  define  the  ampli¬ 
tude  envelope  for  the  object  as  well  as  a  frequency  envelope  (eg.  glissando)  if  desired. 
The  interface  should  be  easy  to  use,  since  this  is  probably  the  first  mode  of  object 
specification  which  the  composer  will  utilize  when  beginning  to  work  with  the  system. 


4. 3. 2. 2.  Frequency  Modulation 

Frequency  modulation,  as  developed  by  John  Chowning  at  Stanford  University,  has  pro¬ 
ven  to  be  a  musically  useful  paradigm  for  synthesizing  sounds  having  time  varying 
spectra.  The  concept  is  well  understood  and  presented  in  Chowning(l973).  The  impor¬ 
tant  point  to  consider  in  implementing  this  module  is  to  maintain  consistency  as  far  as 
possible  with  the  fixed-waveform  mode.  Thus,  there  will  be  a  logical  progression  for  the 
composer  in  moving  to  this  more  musically  useful  mode  of  object  definition. 


4.3.2. 3.  Additive  Synthesis:  Bank  Mode 

The  additive  synthesis  model  is  one  of  the  better  understood  methods  of  defining  the 
acoustical  attributes  of  a  sound  event.  While  it  has  proven  useful  (Grey,  1975),  it 
should  be  remembered  that  it  still  approaches  the  problem  of  timbre  from  the  physical 
domain.  One  of  the  prime  advantages  of  the  technique,  however,  is  the  existence  of 
working  systems  to  analyze  sounds  in  terms  of  the  model.  This  gives  great  flexibility  in 
acoustic  and  psycho-acoustic  research  --  as  well  as  music  —  through  the  technique  of 
"synthesis  by  analysis;"  the  process  of  analysing  sound,  then  re-synthesizing  it  with  or 
without  effecting  transformations  on  its  various  attributes  (as  isolated  by  the  model  of 
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analysis). 


Additive  synthesis  can  be  understood  in  terms  of  the  well  known  technique  of  Fourier 
Analysis.  In  a  simplified  description,  any  complex  periodic  waveform  can  be  described 
in  terms  of  a  set  of  constituent  partials,  or  simplified  waveforms.  In  the  Fourier  series, 
these  partials  are  all  integral  multiples  of  the  fundamental.  They  are  sine  functions 
whose  frequency,  amplitude  and  phase  must  be  specified.  One  of  the  assumptions 
made  in  Fourier  synthesis  is  that  the  complex  waveform  is  periodic  and  of  infinite  dura¬ 
tion:  however,  neither  of  these  conditions  holds  true  for  natural  musical  sounds. 
Furthermore,  the  condition  that  the  constituent  elements  are  integral  multiples  of  the 
fundamental  also  does  not  hold  true  for  natural  tones.  This  is  not  to  say  quasi-periodic 
(i.e.,  pitched)  natural  tones  cannot  be  described  by  constituent  sine  waves;  simply  that 
neither  the  frequency  nor  the  amplitude  of  the  individual  components  is  fixed  in  rela¬ 
tion  to  the  fundamental.  Thus,  the  composite  waveform  is  continually  varying.  It  is 
exactly  this  dynamic  phenomenon  which  characterizes  natural  music  sounds  and 
makes  their  timbre  interesting.  Our  problem,  then,  is  to  provide  an  interface  to  enable 
a  user  to  define,  edit,  etc.,  sounds  according  to  their  constituent  components. 

Required  features:  the  physical  device  which  shall  be  generating  the  sounds  (the  digital 
synthesizer)  has  16  autonomous  digital  oscillators.  At  any  time,  any  oscillator  may 
output  any  one  of  8  different  waveforms.  The  waveforms  are  arbitrary  (i.e.,  any  user 
defined  function)  and  may  include  sine  functions  for  Fourier  synthesis.  The  technique 
is  simply  to  have  one  oscillator  correspond  to  each  partial  to  be  synthesized.  Thus, 
sounds  having  up  to  16  components  may  be  specified.  Using  the  synthesizer  in  this 
manner  explains  why  it  is  refered  to  as  "BANK  MODE".  Having  one  oscillator  correspond 
to  each  component  of  the  complex  constituent  function  desired,  then  requires  the  user 
to  be  able  to  specify  at  least  the  frequency,  amplitude,  waveform,  and  (perhaps)  initial 
phase  for  each  partial.  Furthermore,  it  is  quite  leasable  that  the  frequency  and  ampli¬ 
tude  of  each  component  may  vary  in  time.  Thus  these  parameters  may  need  to  be 
updated  at  a  rate  of  about  50-100Hz. 

Assume  that  --  for  the  time  being  —  the  components  are  integral  multiples  of  the  funda¬ 
mental.  Then,  what  needs  to  be  specified  is  an  amplitude  "ENVELOPE",  (i.e.,  function  of 
amplitude  over  time  where  both  maximum  amplitude  and  duration  are  expressed  in 
relative,  rather  than  absolute  terms)  for  each  component.  Then,  a  fundamental  fre¬ 
quency,  amplitude  scaling  for  composite  sound,  and  duration  must  be  specified.  The 
sound  may  then  be  heard. 

Notable  Points:  Notice  that  the  amplitude  envelopes  could  be  hand  drawn.  Further¬ 
more,  it  is  clear  from  Grey(1975),  that  the  continuous  curve  of  such  envelopes  may  be 
reduced  to  a  series  of  straight  line  segments  to  effect  data  reduction,  with  no  percepti¬ 
ble  change  in  the  sound.  Thirdly,  the  envelopes  should  be  able  to  be  viewed  in  various 
ways.  Finally,  along  the  same  time  axis  for  the  amplitude  envelope  of  each  component, 
it  should  be  optionally  possible  to  specify  a  "FREQUENCY  ENVELOPE",  to  enable  the  fre¬ 
quency  of  each  component  to  vary  in  time,  independent  of  the  others.  All  of  the  above 
features  lend  themselves  to  graphic  techniques,  especially  in  terms  of  means  of  data 
display.  Both  two  and  three  dimensional  representations  are  in  order.  The  problems 
are  rather  straightforward,  so  there  is  good  opportunity  for  a  well  planned  and  efficient 
implementation. 
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4.3.2.4.  Quasi-phonetic  Model:  VOSIM 


We  have  stated  above  that  a  prime  goal  in  object  definition  is  to  enable  the 
specification  of  timbre  according  to  a  perceptual  rather  than  acoustical  model.  Unfor¬ 
tunately,  our  current  understanding  of  timbre  is  such  as  to  limit  our  ability  to  do  so. 
To  develop  this  facility  is  a  prime  research  goal.  At  this  point,  however,  there  are  cer¬ 
tain  approaches  with  which  we  may  start.  The  foremost  of  these  is  derived  from 
psycho-linguistics  and  involves  a  concept  called  the  "cardinal-vowel  quadrangle" 
defined  by  Daniel  Jones  in  1931  (O’Connor,  1973:  106-110).  Essentially,  the  cardinal 
vowel  quadrangle  is  a  two-dimensional  space,  bounded  on  its  four  corners  by  the  four 
prime  cardinal  vowels:  /ee/  -  as  in  "heat";  /ae/  -  as  in  "had";  /ah/  -  as  in  "father";  and 
/oo/  -  as  in  "cool".  Each  point  on  the  surface  of  the  space  defined  by  this  quadrangle 
correlates  to  a  unique  vowel;  furthermore,  all  vowels  in  Indo-European  leinguages  are 
contained  within  the  bounds  of  this  surface.  The  most  striking  property  of  the  qua¬ 
drangle,  however,  is  that  physical  PROXIMITY  in  the  physical  domain  equates  with  sub¬ 
jective  SIMILARITY  in  the  perceptual!  Thus,  the  closer  two  points  are,  the  more  simileir 
are  their  timbre  and  vice  versa  (since  vowel  quality  equates  to  timbre  in  musical 
terms).  The  problem,  then,  remains  to  determine  how  to  exploit  this  aspect  of  linguis¬ 
tic  science  for  our  musical  purposes.  Again,  due  to  the  visual  nature  of  the  two- 
dimensional  quadrangle,  interactive  computer  graphics  could  provide  a  useful  tool  for 
such  exploitation. 

Required  Features:  Obviously,  the  prime  requirement  of  the  system  is  the  mapping 
algorithm  from  a  point  in  the  quadrangle  (as  defined  by  its  two  co-ordinates)  to  the 
parameters  of  the  synthesizer  required  to  generate  the  associated  vowel.  Second,  we 
have  stated  that  associated  with  each  point  is  a  vowel;  but  at  what  pitch  is  that  vowel 
sound  produced?  Thus,  a  pitch  specification  (variable  over  time)  must  be  able  to  be 
made.  Furthermore,  no  time  factor  has  yet  been  specified.  This  can  be  how  long  the 
point  is  pointed  at,  a  numerical  specification,  or  any  other  technique  which  is  appropri¬ 
ate  and  intuitive.  In  addition,  one  may  wish  to  associate  an  amplitude  (again,  variable 
in  time)  with  a  particular  object  which  has  been  defined  according  to  vowel  quality. 
This  should  also  be  possible. 

To  this  stage,  we  have  referred  to  vowels  as  steady  entities  defined  by  points.  Clearly, 
however,  a  line  between  points  has  meaning,  and  in  phonetics  is  termed  a  "dipthong". 
The  difference  between  a  point  and  line  is  seen  in  the  English  words  "a"  and  "I",  respec¬ 
tively.  Most  musical  sounds  are  "dipthong"  in  nature;  that  is,  their  sound  quality  varies 
in  time.  Thus,  not  only  is  the  ability  to  specify  timbres  by  a  line  required,  but  also  the 
ability  to  specify  the  type  of  motion  along  that  line  (linear,  exponential,  random,  etc). 
The  use  of  physical  gestures  using  the  tablet  is  one  obvious  approach.  Finally,  so  far  all 
discussion  has  revolved  around  vowel  (viz.,  quasi-periodic,  or  pitched)  sounds.  How¬ 
ever,  both  music  and  speech  include  non-periodic  sounds,  or  sounds  with  noise  com¬ 
ponents.  In  speech  these  are  the  "consonants",  and  in  music  we  have,  for  example, 
percussive  sounds.  Since  our  means  for  implementing  the  phonetic  model  is  based  on 
the  VOSIM  system  of  Kaegi  (1973,4),  we  have  the  ability  to  impose  varying  degrees  of 
non-periodicity  to  the  vowels,  thereby  generating  consonants.  Thus,  some  sort  of 
potentiometer  should  be  provided  to  define  the  degree  of  periodicity.  Again,  the  user 
should  be  able  to  specify  how  (if  at  all)  this  parameter  varies  in  time. 
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4.3.3.  Score  Editor 


The  argument  can  be  made  that  "Common  Musical  Notation"  (CMN)  is  currently  the 
most  appropriate  notation  to  be  adopted  for  computer  music.  This  point  of  view  is 
expressed  in  Vercoe  (1975),  for  example.  The  opinion  is  that  CMN  is  a  representation  of 
music  with  which  the  composer  is  already  familieir.  Since,  in  using  the  computer,  there 
are  already  enough  "new"  things  for  the  composer  to  cope  with,  we  should  attempt  to 
retain  that  with  which  he  is  familiar  (viz.,  CMN).  The  converse  argument  is  that  CMN  is 
inappropriate,  or  at  least  severely  limiting,  in  terms  of  utilizing  the  full  potential  of 
computer  music.  Consider,  for  example,  that  in  traditional  western  music  the  continu¬ 
ous  domain  of  pitch  has  been  divided  into  discrete  steps  (12  to  the  octave).  CMN,  the 
notation  of  this  system,  is  quite  inappropriate  for  dealing  with  either  the  continuous 
domain,  or  the  division  of  the  octave  (or  any  other  internal)  into  discrete  steps  other 
than  those  12  of  the  chromatic  scale. 

Our  approach  tries  to  consider  both  these  points  of  view,  while  not  compromising 
either.  Simply,  it  is  felt  that  the  two  approaches  can  peacefully  co-exist.  For  those 
who  would  be  more  comfortable  doing  so,  they  may  begin  work  using  the  notational 
scheme  with  which  they  are  familiar  (e.g.,  CMN).  However,  once  they  are  comfortable 
in  the  computer-assisted  environment,  they  should  be  able  to  adopt  alternative  means 
of  notation.  Furthermore,  it  is  clear  that  there  is  no  need  for  mutual  exclusion  of 
different  forms  of  notation.  The  same  thing  can  be  represented  in  different  ways,  and 
which  is  most  appropriate  depends  on  the  (musical)  context.  Therefore,  the  data  base 
for  different  forms  of  notation  should  be  common  --  merely  interpreted  differently  for 
different  notational  schemes.  Thus,  a  variety  of  notational  systems  should  be  available 
to  be  of  use  singly  or  in  combination  so  as  to  best  facilitate  the  composer’s  task.  In 
conclusion,  while  various  notational  schemes  are  presented  below,  this  approach  of 
compatability  among  notations  should  be  kept  in  mind.  We  view  CMN  as  a  particular 
form  of  time-line  notation  which  happens  to  be  rather  well  developed.  Similarly,  music 
notated  in  Cartesian  space,  with  the  ’X’  axis  representing  time,  should  be  able  to  be 
displayed  superimposed  over  various  grids  -  including  the  5-line  staff  of  CMN. 


4.3.3. 1.  Common  M^Lsic  Notation 

While  it  is  clear  that  given  an  appropriate  "script",  the  computer  is  able  to  "perform"  a 
composition  on  the  synthesizer,  it  remains  to  define  how  a  composer  is  to  specify  such 
a  script  (or  "Score")  in  the  first  place.  Traditionally,  this  has  been  done  for  instrumen¬ 
talists  using  CMN.  Several  computer  music  instalations  have  adopted  CMN  as  well. 
While  the  music  which  can  be  produced  is  stylistically  limited  by  the  adoption  of  this 
notation,  the  benefits  in  providing  the  composer  a  language  with  which  he  is  familiar 
are  considerable  from  a  man-machine  communications  point  of  view.  We  wish  to  be 
able  to  provide  such  a  facility  on  our  system,  but  with  certain  conditions  to  avoid  the 
pit-falls  of  previous  researchers.  To  begin  with,  v/e  should  state  the  limiting  condition 
that  our  intention  is  NOT  to  do  computer  aided  music  page  layout  or  printing:  there¬ 
fore,  many  of  the  notational  niceties  of  printed  music  need  not  be  included.  We  simply 
want  those  features  of  CMN  which  enable  us  to  graphically  specify  the  pitch/time 
structure  in  an  intuitive  manner,  using  a  notational  scheme  with  which  we  are  familiar, 
and  which  we  can  visually  scan  for  errors,  etc.  Given  this  first  condition,  it  is  clear  that 
we  may  take  certain  liberties  with  CMN,  as  long  as  they  (a)  do  not  negate  our  original 
motivation  for  adopting  the  notational  scheme,  and  (b)  increase  the  efficiency  of 
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working,  from  the  user’s  point  of  view.  Examples  of  such  "liberties"  would  include  con¬ 
sidering  the  staff  simply  as  a  time  line  which  happens  to  have  a  grid  on  the  vertical 
axis.  Thus,  in  a  score  the  staff  is  not  broken  at  the  right  margin  to  start  a  new  line; 
rather,  it  continues  horizontally  (on  either  side)  outside  the  viewpoint  of  the  CRT. 
Thus,  during  performance,  several  staves  (each  representing  one  voice,  for  example  as 
in  an  orchestral  score)  are  vertically  aligned,  and  scroll  horizontally  in  synchronization 
with  the  sound.  During  such  performance,  the  user  may  execute  a  "HALT"  command, 
and  begin  to  edit,  jump  ahead,  or  to  exercise  some  other  control  option. 

Required  Features:  Central  to  the  approach  to  be  taken  is  the  concept  that  the  user 
should  be  allowed  to  address  himself  to  the  music  at  various  structural  levels.  Thus,  he 
should  be  able  to  execute  commands  affecting  the  entire  composition,  all  the  notes  on 
a  single  staff,  or  a  single  note.  This  is  just  the  beginning,  however.  In  addition,  the  user 
should  be  able  to  isolate  structures  or  motifs,  and  copy,  transform,  save,  or  perform 
other  operations  on  them.  He  should  be  able  to  access  a  particular  place  in  the  score 
by  various  means,  including  scrolling,  jumping  a  particular  offset,  or  jumping  to  a  pre¬ 
viously  named  spot  (analogous  to  orchestral  rehearsal  markings). 

Notable  Points:  We  must  consider  carefully  the  nature  of  the  command  structure 
whereby  the  user  inputs  and  edits  notes  (including  pitch,  duration),  motives,  etc.  Dev¬ 
ices  such  as  a  character  recognizer  are  available.  In  addition,  if  —  as  we  have  stated  — 
the  user  should  be  able  to  address  his  commands  to  various  levels  in  a  structural 
hierarchy,  this  can  be  seen  as  executing  (where  appropriate)  the  same  command  on 
the  descendants  of  nodes  at  different  levels  in  a  "syntax  tree"  describing  the  musical 
structure  in  question.  Thus,  a  continuity  in  commands  should  be  able  to  be  maintained 
at  most  levels  in  the  hierarchy. 


4.3.3. 8.  Time  Line  Notation 

It  has  already  been  pointed  out  that  CMN  is  just  a  particular  instance  of  time  line  nota¬ 
tion.  What  we  would  like  to  obtain  is  an  editor  which  enables  us  to  work  in  the  more 
general  case  of  Cartesian  space,  where  time  is  represented  on  the  "X"  axis  and  pitch, 
for  example,  on  the  "Y". 

Required  Features:  Such  notation  would  give  us  a  means  of  viewing  pitch/time  relation¬ 
ships  in  a  manner  not  possible  with  CMN.  This  is  seen,  for  example,  in  considering  that 
a  "score"  in  CMN  —  as  outlined  above  —  is  essentially  a  set  of  parallel  time  lines  with 
grids  in  the  form  of  5-line  staves.  With  the  time  line  notation,  what  we  would  like  to  be 
able  to  do  is  view  the  same  six  voices,  for  example,  but  superimposed  on  a  common  "Y" 
axis.  Furthermore,  we  should  be  able  to  identify  (or  retain)  the  individual  voices  as 
required  (by  having  notes  of  each  voice  identified  by  different  symbols,  etc.).  We 
should  be  able  to  scroll  left  to  right  or  up  and  down  within  the  bounds  of  the  Cartesian 
space  encompassing  a  composition.  As  well,  we  should  be  able  to  zoom  in  (for  detail)  or 
out  (for  overall  view)  of  the  composition.  Furthermore,  we  should  be  able  to  effect 
such  zooms  for  the  "X"  and  "Y"  axis  independently  of  one  another.  Thus,  the  entire 
duration  of  a  composition  may  be  seen  within  the  viewport  while  still  retaining  full  scal¬ 
ing  on  the  "Y"  axis.  Conversel3^  without  affecting  the  time  axis,  we  should  be  able  to 
expand  --  for  fine  detail  —  the  scale  of  the  pitch  axis. 
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Most  of  the  features  specified  for  CMN  are  applicable  for  time  line  notation  as  well. 
Scrolling,  working  with  groups  of  sounds,  selective  viewing,  etc.,  are  all  required.  In 
addition,  the  composer  should  be  able  to  superimpose  various  grids  (including  staves  of 
CMN)  over  the  Cartesian  space.  Therefore,  a  method  of  defining  such  grids  as  well  as  a 
menu  of  system  defined  ones  (such  as  frequency,  pitch  and  time  scales)  should  both  be 
provided. 

Notable  Points:  One  should  be  aware  that  the  key  problem  in  this  aspect  of  the  project 
is  the  fact  that  we  are  trying  to  represent  several  attributes  in  2-dimensional  space. 
For  example,  even  if  we  can  represent  the  frequency/time  structure,  how  are  the 
amplitudes,  groupings,  spatial  location,  and  timbres  (as  determined  by  the  associated 
objects)  going  to  be  represented,  much  less  specified?  Clearly,  the  solution  lies  (as  in 
CMN)  in  the  adoption  of  a  scheme  of  symbols  and  other  cues  (e.g.,  intensity,  shape, 
size,  blinking,  etc.).  The  task  of  the  programmer,  then,  is  to  interrogate  the  com¬ 
posers  available  in  order  to  determine  which  cues  are  most  applicable  in  a  particular 
musiced  context. 


4.3.3. 3.  Three  Dimensional  Tree  Display 

In  the  above  described  time  line  notation,  one  of  the  problems  was  seen  to  be  in  the 
displaying  the  structural  relationships  among  notes.  We  have,  however,  pointed  out 
that  we  can  consider  a  composition  as  a  hierarchy  of  structures  —  where  the  highest 
level  structure  is  the  composition  itself,  and  the  lowest,  a  single  sound  event.  In 
between,  the  structural  associations  can  be  represented  by  a  "syntax"  tree  whose 
nodes  correspond  to  the  structures  of  the  "deep  structure."  Seen  in  this  context,  the 
root  of  the  tree  is  the  highest  level,  as  already  mentioned,  and  the  leaves  are  the  other 
special  case:  the  notes  or  "surface  structure"  of  the  composition.  Any  structure  then 
consists  of  the  sub-tree  under  the  node  associated  with  that  structure. 

Required  Features:  What  we  would  like,  therefore,  would  be  to  be  able  to  display  and 
edit  a  composition  according  to  the  structures  displayed  m  tree  fashion.  Thus,  point¬ 
ing  at  a  node  would  enable  particular  operations,  such  as  performance,  to  be  carried 
out  on  the  associated  structure.  The  tree  could  be  "pruned"  or  a  structure  copied, 
with  the  copy  being  attached  to  another  portion  of  the  tree  (perhaps  with  some 
transformation  being  effected  in  the  process). 

Notable  Points:  Notice  that  a  tree  structure  as  described  thus  far  is  two  dimensional, 
and  tells  us  nothing  about  the  pitch/time  structure  of  the  composition.  Consider,  for 
example,  that  the  notes  of  a  2-note  chord  may  each  be  associated  with  a  different 
structure.  How  would  such  a  tree  indicate  that  they  occur  together?  One  method  is  to 
have  a  three  dimensional  tree.  In  such  a  tree,  all  of  the  arcs  and  nodes,  except  those 
of  leaves,  could  exist  on  a  single  plane,  defined  by  the  "X"  and  "Y"  axis.  The  arcs  to  the 
"leaves"  could  then  extend  to  the  "notes"  as  sorted  according  to  time  on  th  "Z"  axis. 
Thus,  if  we  are  provided  a  tool  for  enabling  us  to  rotate,  etc.,  the  tree  for  examination 
and  editing,  we  have  increased  the  power  of  our  system.  Additional  cues,  such  as  pitch, 
amplitude,  etc.,  could  be  incorporated  into  this  representation  with  a  little  thought. 
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4.3.4.  ChaTinel  Distribution  Editor 


We  have  four  "voices"  of  sounds,  each  of  which  may  be  output  from  any  or  all  of  16 
loudspeakers.  The  volume  at  which  each  sound  is  transduced  may  be  independently 
controlled  for  each  of  the  16  channels.  Thus,  if  the  speakers  are  spatially  distributed 
in  a  listening  room,  by  "panning"  or  "moving"  the  sounds  from  speaker-to-speaker  we 
are  moving  them  in  space  as  well.  Thus,  we  are  capable  of  having  four  sounds  moving 
independently  of  one  another,  over  a  space  defined  by  the  physical  location  of  16 
loudspeakers. 

Problem:  the  appeal  to  the  composer  of  the  above  is  that  he  may  now  "choreograph" 
his  music  in  space.  The  key  problem  is  designing  a  graphics  interface  which  enables 
him  to  do  so  easily! 

Required  Features:  First,  the  user  must  be  able  to  somehow  "perform"  the  spatializa- 
tion  of  one  or  more  of  the  four  voices,  in  real-time.  Furthermore,  this  "performance" 
must  be  monitored  and  remembered  (for  future  reference)  by  the  computer.  "Take  A" 
of  a  performance  of  voice  one  must,  for  example,  be  able  to  be  played  simultaneously 
with  "take  B"  of  a  performance  of  voice  two.  Furthermore,  we  should  be  able  to  form  a 
new  "take  C"  of  voice  one,  simply  by  combining,  for  example,  the  first  half  of  "take  A" 
and  second  half  of  "take  B."  Thus,  we  see  that  not  only  must  we  provide  facilities  for 
saving  a  performance,  but  full  editing  capabilities  as  well.  These  must  include  both 
"patch-work"  non-real-time  functions  (analogous  to  splicing  film)  and  real-time  "fine- 
tuning"  of  a  previous  "take",  thereby  creating  a  new  "take"  which  may  be  saved,  edited, 
etc.,  as  is  the  user’s  wont.  Finally,  all  "takes"  described  so  far  have  been  derived 
(albeit,  perhaps,  indirectly)  from  a  real-time  performance.  It  is  clear,  however,  that  a 
mechanism  should  be  provided  (e.g.,  use  of  stored  functions  over  time,  algebraic 
expressions,  etc.)  to  enable  a  motion  pattern  to  be  described  non-real- time.  A  sample 
situation,  for  example:  "let  voice  ’a’  rotate  clockwise  for  the  duration  of  the  piece, 
starting  at  such  and  such  a  speed,  and  gradually  accelerating  at  such  and  such  a  rate". 
Clearly,  a  little  thought  shows  that  graphics  and  the  ability  to  monitor  physical  ges¬ 
tures  could  provide  a  powerful  means  to  enable  such  specifications. 

Notable  points:  It  seems  worthwhile  to  mention  explicitly  a  few  of  the  more  overt 
points  to  consider:  the  performance  medium,  e.g.,  the  tablet,  and  alternatives;  graphi¬ 
cal  representation  of  voices  in  the  listening  environment  in  time;  we  are  dealing  mainly 
with  angular  localization,  reverb  is  not  considered,  so  control  of  distance  cues  is  nomi¬ 
nal;  the  mapping  algorithm  must  be  of  the  form  Pnt(x,y)  ->  Amp(v[l],  v[2],  ...v[l6])  for 
each  of  the  4  voices  (where  P  is  the  point  on  tablet  having  co-ordinates  "x"  and  "y",  and 
for  Amp(v[n]),  "v"  is  the  amplitude  setting  for  that  voice  from  speaker  "n").  Thus,  to 
implement  the  function,  we  must  have  a  method  for  specifying  speaker  location  rela¬ 
tive  to  listening  space  (e.g.,  tablet  and  CRT),  and  then  calculate  formulas  for  amplitude 
distribution. 
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4.3.5.  Collection  Network  Editor 


The  problem  of  controlling  the  collection  network  can  be  considered  as  similar  to  con¬ 
trolling  a  16  channel  audio  mixer  in  a  public  address  (PA)  application.  Currently  avail¬ 
able  equipment  for  PA  work  is  generally  not  special  purpose;  rather,  it  has  been  studio 
equipment  taken  out  of  its  intended  context,  and  adapted  to  a  new  task  (for  which  it  is 
not  particularly  well  suited).  Given  the  array  of  knobs  and  dials  confronting  an  opera¬ 
tor,  we  want  to  provide  facilities  where  the  modifications,  changes,  etc.,  can  be  made 
quickly  and  reliably. 

The  Problem:  the  apparatus  to  be  controlled  is  as  follows.  (If  it  seems  complex,  then 
one  can  appreciate  the  problem  of  the  operator  of  current  manually  operated  con¬ 
soles.)  We  have  16  input  channels.  Each  channel  can  accept  an  analogue  signal  such  as 
an  electronic  instrument,  or  a  microphone.  Each  of  the  16  inputs  is  initially  kept  auto¬ 
nomous.  At  this  stage,  each  can  have  its  input  level  normalized  by  the  "INPUT 
ATTENUATOR".  (This  device  is  not  used  as  a  volume  control;  rather,  to  bring  inputs  of 
different  signal  types  to  a  common  standard.)  Each  normalized  input  may  then  be 
independently  processed  by  a  sophisticated  tone  control  called  a  "4  BAND  EQUALIZER". 
This  is  simply  4  continuously  variable  (cut  or  boost)  tone  controls,  one  for  each  of  the  4 
frequency  bands:  HIGH,  HIGH-MID,  LOW-MID,  and  LOW. 

The  final  controls  to  be  described  enable  the  central  task  of  the  mixer  to  be  carried 
out.  That  is,  the  mixing,  or  "blending"  of  the  (up  to)  16  inputs  into  (up  to)  4  outputs. 
Since  there  are  4  output  channels  possible,  we  see  that  for  each  input,  we  need  4 
"LEVEL  CONTROLS".  This  enables  us  to  distribute  each  input,  variably,  over  each  of  the 
4  outputs.  We  see  then,  that  there  are  16  inputs,  each  with  9  continuously  variable  con¬ 
trols,  giving  144  controls  for  the  operator  to  contend  with;  all  in  a  "no  second  chance" 
environment!  This  is  not  all,  however.  An  integral  part  of  the  collection  (viz.,  PA  mix¬ 
ing)  process,  is  enabling  the  performer  to  hear  himself  (perhaps  differently  than  the 
audience  hears  him),  through  a  device  known  as  a  "MONITOR  SPEAKER".  Our  system 
has  4  monitor  speakers.  Each  monitor  speaker  is  capable  of  outputting  to  a  performer, 
a  unique  "mix"  of  the  four  main  output  channels  of  the  mixer.  This  is  accomplished  by 
a  small  4  to  1  mixer  associated  with  each  monitor.  Each  "MONITOR  MIX"  consists  of  4 
"MONITOR  LEVEL"  controls,  one  for  each  of  the  4  output  channels  of  the  main  mixer. 
We  are  now  capable  of  appreciating  the  full  complexity  of  the  control  task  to  be  per¬ 
formed.  Four  monitors,  each  with  4  controls,  -  combined  with  the  144  controls  already 
described  -  gives  us  a  total  of  160  continuously  variable  controls  to  be  manipulated  in 
real-time.  The  potential  for  data  reduction  through  reasonable  task  analysis  combined 
with  interactive  computer  graphics  is  enormous. 

Required  Features:  the  problem  can  be  considered  in  terms  of  three  concerns: 
"knobs",  "groups",  and  "pre-sets".  The  following  discussion  has  much  in  common  with 
the  design  of  automated  theatre  lighting  systems;  however,  the  "state  of  the  art"  in 
lighting  control  is  far  ahead  of  that  of  PA  systems.  A  strange  situation,  given  the  simi¬ 
larity  of  the  problems.  Regardless,  we  shall  now  attempt  to  explain  the  three  concerns 
outlined  above.  First,  by  "knobs"  we  mean  simply  that  any  of  the  160  knobs  in  the  sys¬ 
tem  should  be  individually  accessible,  and  modifiable  in  real-time.  This  can  obviously 
be  facilitated  using  graphic  techniques.  Second:  "groupings"  is  simply  a  more  sophisti¬ 
cated  version  of  knobs.  With  groupings,  we  must  provide  an  editor  to  enable  the  opera¬ 
tor  (before  or  during  performance)  to  form  "associations"  among  knobs;  that  is,  tying 
all  "user  associated"  knobs  to  one  new,  single  knob.  Thus,  any  change  on  the  group  "A" 
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knob  (where  A  is  a  user  defined  label  --  graphic  or  otherwise)  will  be  reflected  on  all 
knobs  of  the  association  "A”.  Thirdly,  by  ’’pre-sets’',  we  mean  that  we  can  obtain  a 
named  ’’snap-shot”  of  the  mixer  at  any  time,  and  store  it  for  future  use.  It  is  clear, 
however,  that  there  must  be  other  ways  of  obtaining  pre-sets  than  simply  configuring 
the  board  and  commanding:  ’’remember  this”.  Thus,  an  editor  for  pre-sets  must  be 
developed.  The  user  should  be  able  to  define,  call  up,  and  modify  pre-sets  both  before 
and  during  performance.  Furthermore,  interpolation  between  two  pre-sets,  controlled 
by  a  "cross-fader”,  for  example,  should  be  possible.  Thus,  we  see  the  use  of  pre-sets  as 
being  somewhat  analogous  to  "key-frame  animation”  in  graphics. 

Notable  Points:  It  is  clear  that  the  prime  consideration  in  PA  applications,  in  contrast 
to  "studio”  applications,  is  not  the  ability  to  ’’store”  or  "play-back”  performances. 
Rather,  we  want  to  be  able  to  quickly  reconfigure  and  control  the  mixer  in  a  simple, 
intuitive  manner.  Thus,  the  graphic  representation/command  language  is  of  utmost 
importance.  Options  worth  considering,  for  example,  include  determining  a  represen¬ 
tation  of  a  "virtual”  mixer  panel;  alternatively,  and  perhaps  more  interesting,  a 
representation  of  the  "stage”  area.  The  use  of  "reserved”  pre-sets,  such  as  "all  null” 
and  "current  state”  would  also  be  worth  considering.  In  a  similar  vein,  reserved 
groups,  such  as  "grand  master”,  affecting  all  64  amplitude  controls,  or  "master",  one 
for  each  of  the  4  channels,  could  be  defined. 


4.4.  The  Research  Team  and  their  Respective  Roles 

In  order  to  successfully  carry  out  the  research  described  above,  a  team  whose 
members  have  quite  diverse  backgrounds  has  been  assembled.  The  members  of  the 
team,  their  personal  interests  in  the  project,  and  their  respective  areas  of  responsibil¬ 
ity  are  outlined  below  under  the  appropriate  headings. 


A:. A:.l.  Principal  Investigators 

Overall  responsibility  for  the  project  is  held  by  Prof.  L.  Mezei.  Besides  coordinating  the 
overall  research,  his  chief  interest  is  in  the  communicational  and  artistic  aspects  of 
the  project.  His  chief  area  of  research  in  the  past  has  been  the  use  of  computers  in 
the  humanities  and  the  social  implications  of  computers.  The  current  project 
represents  a  continuation  in  this  domain. 

Responsibility  for  the  musical  aspects  of  the  project  is  with  Dean  G.  Ciamaga  of  the 
Faculty  of  Music.  Based  on  both  his  own  experience  with  the  project,  and  his  supervi¬ 
sion  of  his  graduate  music  students  who  will  also  be  test  subjects,  he  will  ensure  the 
musical  credibility  of  the  project.  His  technological  as  well  as  musical  involvement, 
therefore,  will  be  similar  to  his  earlier  collaboration  with  Gabura  in  the  PIPER  project 
(Gabura  and  Ciamaga,  1968),  an  earlier  computer  music  project  at  this  University. 

Prof.  R.  Baecker  has  a  cross-appointment  with  the  Departments  of  Computer  Science 
and  Electrical  Engineering  at  the  University  of  Toronto.  Besides  providing  a  link 
between  these  two  disciplines  in  the  project,  his  main  interest  and  responsibility  is  the 
design  of  the  graphics  oriented  command  language  to  be  used  in  the  system. 
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The  responsibility  of  Prof.  K.  C.  Smith,  chairman  of  the  Department  of  Electrical 
Engineering  at  the  University  of  Toronto,  is  to  provide  the  expertise  in  Electrical 
Engineering.  His  involvement  in  the  technological  problems  of  music  dates  back  to  the 
early  days  of  electronic  music.  In  the  current  project,  he  is  in  charge  of  high  level 
electronic  design,  and  overseeing  the  contracting  of  the  lower  level  technological 
aspects  of  the  work.  Regarding  the  latter,  this  will  be  carried  out  by  graduate  and 
undergraduate  students  and  shop  personnel  employed  directly  for  this  purpose. 


4.4.2.  Research  Assistants 

William  Buxton  is  trained  both  as  a  musician  and  as  a  computer  scientist.  He  coordi¬ 
nates  the  project  and  is  employed  as  a  full  time  research  assistant  for  the  duration  of 
the  project.  Under  the  direction  of  the  principal  investigators,  he  will  be  responsible 
for  the  bulk  of  the  programming  for  the  project,  and  will  provide  an  additional  bridge 
between  the  musical  and  technological  aspects  of  the  research. 


4.4.3.  Engineering  Support  \ 

The  bulk  of  the  digital  engineering  for  the  project  has  been  undertaken  under  contract 
by  Mr.  Al  Fogels,  an  employee  of  the  University  of  Toronto  Medical  Computing  Group. 
Design  of  the  analogue  portions  of  the  system,  including  the  distribution  system  and 
collection  network  has  been  carried  out  by  Mr.  Guy  Fedorkow,  an  M.  Sc.  student  super¬ 
vised  by  Prof.  Smith.  Mr.  Laurence  Sasaki,  a  Ph.D.  candidate  of  Prof.  Smith  has  pro¬ 
vided  hardware  consulting.  The  actual  construction  of  most  of  the  hardware  built  has 
been  by  Mr.  Scott  MacKenzie,  an  honours  graduate  in  music  from  Queen’s  University, 
and  currently  a  third  year  student  in  electrical  technology  at  Durham  College,  Oshawa. 
This  team  has  proven  very  productive,  and  we  intend  to  maintain  this  mode  of  opera¬ 
tion  in  the  future. 


4.4.4.  Student  Help 

The  work  accomplished  so  far  has  in  no  small  way  been  due  to  the  help  of  many  gradu¬ 
ate  and  undergraduate  students  of  the  principal  investigators.  Such  students  have 
been  attracted  to  the  project  by  personal  interest,  and  they  have  made  a  real  contribu¬ 
tion.  Bill  Reeves,  a  doctoral  student  of  Prof.  Baecker  and  Robert  Pike,  a  student 
employee,  are  largely  responsible  for  the  performance  software  module  for  the  syn¬ 
thesizer.  Reeves  also  assisted  an  M.Sc.  student  of  Prof.  Mezei’s,  Greg  Hill,  in  virriting  the 
device  driver.  Rob  Cairns,  a  student  of  Prof.  Smith,  is  in  the  process  of  preparing  a 
fourth  year  thesis  studying  the  problem  of  pitch  extraction  in  real-time.  Finally,  a 
great  deal  of  the  user  oriented  software  which  will  be  described  in  section  5  has  been 
written  as  term  projects  of  students  in  Prof.  Baecker’s  graduate  course  in  computer 
graphics.  This  software,  written  under  the  supervision  of  Prof.  Baecker,  Bill  Reeves, 
and  W.  Buxton  has  proven  a  great  benefit  to  the  project.  The  type  of  flexibility  shown 
by  both  Prof.  Baecker  and  this  class  are  indicative  of  the  creative  environment  in  which 
this  project  has  flourished. 


-  19  - 


In  the  coming  year,  it  is  clear  that  there  is  going  to  have  to  be  a  large  programming 
effort  in  order  to  keep  on  schedule.  We  have,  therefore,  budgeted  funds  to  enable  us  to 
hire  student  assistants  in  the  next  grant  period  to  aid  in  this  effort.  We  propose  to  pro¬ 
vide  for  the  equivalent  of  one  undergraduate  student  for  the  term  of  the  project  (18 
months)  as  well  as  another  one  hired  only  for  the  two  4  month  summer  periods  encom¬ 
passed  in  the  grant  period.  This,  in  combination  with  the  work  of  W.  Buxton  should  pro¬ 
vide  adequate  support  in  the  software  domain. 


4.4.5.  Music  Consultants 

Central  to  the  success  of  the  project  is  the  active  involvement  of  musically  sophisti¬ 
cated  composers.  Firstly,  graduate  composition  and  theory  students  of  Dean  Ciamaga 
will  form  part  of  this  group.  Students  in  his  graduate  seminar  began  using  the  system 
in  a  serious  manner  in  February,  1978.  In  addition,  members  of  the  Canadian  Elec¬ 
tronic  Ensemble  (David  Jaeger,  David  Grimes,  James  Montgomery,  and  Laurence  Lake) 
have  been  taking  an  active  role  in  the  design  of  the  system  to  date.  Members  of  this 
ensemble  are  all  active  composers,  have  graduate  degrees  in  music,  and  have  exten¬ 
sive  experience  in  electronic  music.  Finally,  Mr.  Dennis  Patrick,  the  Manager  of  the 
University  of  Toronto's  Electronic  Music  Studio,  and  Ms.  Norma  Beecroft,  a  well  known 
Canadian  composer,  have  also  become  active  members  of  the  project.  Mr.  Grimes  and 
Ms.  Beecroft  have  recently  received  Canada  Council  Arts  grants  to  enable  them  to  par¬ 
ticipate  more  fully  in  the  project.  Prof.  Peter  Clements  of  the  University  of  Western 
Ontario  has  also  made  arrangements  to  work  with  the  project  during  the  summer  of 
1978.  In  summary,  we  have  a  large  degree  of  musical  expertise  at  our  disposal.  Under 
the  guidance  of  Dean  Ciamaga,  we  feel  optimistic  about  the  potential  for  success. 


4.5.  Publishing  Plans 

As  stated  in  section  5.5  of  this  document:  Publications,  we  have  initiating  a  series  of 
technical  memos  (of  which  this  document  is  the  first)  to  facilitate  the  dissemination  of 
our  results.  The  purpose  of  this  section  is  to  clarify  our  intentions  for  publication 
through  this  and  (primarily)  other  outlets.  To  begin  with,  it  is  clear  that  music  related 
studies  should  be  submitted  to  journals  such  as:  The  Journal  of  Music  Theory.  Inter¬ 
face,  or  The  Computer  Music  Journal.  In  addition,  there  are  several  other  areas  in 
which  we  foresee  obtaining  results  which  warrant  publication.  There  are,  for  example, 
problems  in  data  structures,  perception,  graphics  based  command  languages,  and 
hierarchic  structures:  the  solutions  to  which  are  of  interest  beyond  our  project.  As 
well,  in  Electrical  Engineering  we  anticipate  publications  on  various  levels.  The  first  of 
these  encompasses  detailed  information  such  as  manuals,  which  enable  reproduceabil- 
ity  of  our  developments  at  other  institutions.  Secondly,  we  are  planning  presentations 
which  discuss  design  problems  and  considerations  which  we  feel  are  of  value  to  other 
system  designers.  Finally,  on  a  less  global  level,  we  expect  to  publish  detailed  descrip¬ 
tions  of  various  problems  and  developments  which  would  be  of  interest  to  specialists. 
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4.6.  Sources  of  Funding 


The  SSSP  exists  under  the  auspices  of  the  Computer  Systems  Research  Group  of  the 
University  of  Toronto.  This  group  is  a  special  interest  research  group  made  up  of 
members  of  the  Universitiy’s  departments  of  Electrical  Engineering  and  Computer  Sci¬ 
ence.  Physical  support  (support  steLff,  office  space,  computing  facilities)  comes  from 
these  departments  as  well  as  the  Faculty  of  Music. 

Direct  financial  support  comes  from  the  Canada  Council  Humanities  and  Social  Sci¬ 
ences  Division.  This  funding  began  in  January  1977  and  runs  to  1978.  Work  reported  in 
this  document  has  been  carried  out  during  this  period.  An  application  for  funding 
renewal  for  another  18  month  period  is  currently  pending  with  the  Canada  Council. 


5.  Work  Already  Completed  and  in  Progress 


5.1.  General 

This  section  constitutes  a  report  on  progress  over  the  first  12  months  of  the  project. 
For  the  complete  context,  sections  1  to  4  of  this  document  should  be  considered.  In 
the  report  it  can  be  seen  that  considerable  progress  has  been  made  in  a  relatively 
short  period  of  time.  This  is  all  the  more  significant  when  one  considers  the  interdisci¬ 
plinary  nature  of  the  team.  What  achievements  have  been  made  are  largely  due  to  the 
active  participation  of  all  team  members  and  the  fact  that  all  members  keep  abreast  of 
each  other’s  progress  through  our  weekly  meetings.  In  addition,  no  small  contribution 
has  been  made  as  the  result  of  visits  —  both  from  and  to  —  several  researchers  prom¬ 
inent  in  the  field. 

The  first  phase  of  the  project  has  been  largely  developmental.  We  have  now  established 
what  we  feel  is  an  excellent  facility  on  which  to  undertake  the  program  of  work  outlined 
in  section  4  of  this  document:  Research  Plan  and  Methods.  While  discussion  of  this 
facility  concerns  largely  hardware,  significant  progress  has  been  made  in  software 
development  and  theoretical  work  (as  is  evident  in  other  parts  of  this  proposal,  as  well 
as  several  papers  either  completed  or  in  preparation).  Construction  of  the  digital  syn¬ 
thesizer  is  —  except  for  final  implementation  of  VOSIM  —  completed.  The  device  now 
resides  permanently  on  line,  connected  to  the  PDP-11/45  which  the  project  is  using. 
Besides  diagnostic  software  and  a  driver,  a  first  implementation  of  a  performance  pro¬ 
gram  (to  perform  predefined  scores)  is  operational.  A  musician  can  now  come  in  and  -- 
primitively  --  define,  audition  and  modify  a  musical  score.  (It  is  the  aim  of  the  next 
phase  of  the  research  to  determine  what  tools  he  needs  to  facilitate  this  task.)  Perhaps 
the  most  impressive  aspect  of  the  system  thus  far  (even  to  us),  is  that  a  user  is  able  to 
perform  16  voices  of  complex  sound  in  real-time,  on  a  mini-computer  which  is  running 
under  a  time-sharing  operating  system,  with  very  little  degradation  of  performance  to 
the  other  (up  to  9)  users  of  the  system!  From  this  fact  one  can  truly  appreciate  the 
economy  and  low  computational  overhead  involved  in  a  carefully  conceived  mixed  digi¬ 
tal  system. 

To  conclude  this  introduction,  we  feel  that  the  past  twelve  months  has  not  only  put  us 
on  a  strong  footing  for  the  next  phase  of  the  project,  but  established  the  credibility  of 
the  research  team.  We  will  now  proceed  to  discuss  in  detail  the  results  of  the  past 
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year’s  work. 


5.2.  Hardware 


5.2.1.  Digital  Synthesizer 

The  synthesizer  is  one  of  the  most  important  components  in  the  system.  Generally 
described,  it  consists  of  one  "real"  oscillator  which  is  time-division-multiplexed  into  six¬ 
teen  "virtual"  oscillators.  The  device  was  designed  by  a  team  headed  by  Prof.  Smith, 
consisting  of  Buxton,  Fogels,  Fedorkow,  and  Sasaki.  Construction  was  by  MacKenzie. 
The  design  owes  much  to  the  Dartmouth  synthesizer  (Alonso  et  al.,  1976)  as  well  as  the 
VOSIM  oscillator  (Tempelaars,  in  press).  A  visit  to  Dartmouth  College,  by  Buxton, 
proved  most  worthwhile  in  solving  many  design  problems. 

The  device  is  essentially  a  fixed  sampling  rate,  accumulator-type  digital  oscillator.  The 
sampling  rate  of  each  oscillator  is  50  kHz,  giving  a  bandwidth  of  25  kHz.  Dynamic  range 
is  well  over  60  dB  (and  should  improve  with  further  adjustment)  while  frequency  resolu¬ 
tion  is  approximately  .7  Hz  (linear  scale)  over  the  entire  bandwidth.  This  wiU  shortly  be 
improved  to  enable  resolution  of  less  than  1  "cent"  at  even  extremely  low  frequencies. 
The  output  of  each  oscillator  can  be  output  to  one  of  four  output  busses  which  may 
then  either  be  fed  directly  to  an  amplifier,  or  to  the  channel  distributor  (discussed 
below).  The  waveform  output  by  each  generator  may  not  only  be  user  defined  —  up  to  8 
waveforms  available  at  one  time  —  but  one  may  switch  waveforms  in  mid-cycle.  This  is 
possible  since  the  16  oscillators  share  a  16k  buffer  of  12-bit  words  to  store  waveforms. 
This  16k  of  RAM  is  partitioned  into  0  2k  blocks,  one  for  each  of  the  8  possible  waveforms 
defined  by  the  user  or  system.  Besides  this  memory  configuration,  what  makes  this 
synthesizer  particularly  interesting  is  the  fact  that  the  oscillators  may  be  used  to  gen¬ 
erate  sounds  according  to  various  synthesis  modes.  Thus,  one  goes  a  long  way  towards 
having  a  "universal  module"  —  that  is,  all  modules  of  a  uniform  type  (ease  of  conceptu¬ 
alization,  communication  etc.).  This  is  in  direct  contrast  with  analogue  synthesizers, 
and  yet  a  very  wide  repertoire  of  sounds  is  possible  (including  all  phonemes  in  Indo- 
European  languages,  for  example).  We  shall  proceeed,  therefore,  to  describe  the  four 
modes  of  the  oscillators  in  sufficient  detail  as  to  enable  the  reader  to  appreciate  the 
various  features. 


5.2. 1.1.  Indrpendent  Voice  Mode: 

Each  oscillator  can  be  considered  as  an  independent  voice.  For  each  voice 
used,  one  of  the  0  waveforms  can  be  selected  and  output  at  a  specified  fre¬ 
quency  and  amplitude.  The  timbre  of  the  output  of  a  given  oscillator  remains 
unchanged  until  a  diff’erent  waveform  is  selected.  While  pedagogically  interest¬ 
ing,  this  is  perhaps  the  most  common  and  (musically)  least  interesting  method 
of  sound  synthesis. 
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5.2. 1.2.  Bank  Mode: 


Up  to  16  oscillators  are  utilized  in  peirallel  to  provide  a  single  voice.  When,  for 
example,  the  function  selected  by  each  oscillator  is  a  sinusoid,  Fourier  syn¬ 
thesis  for  up  to  16  partials  is  enabled.  The  user  is  then  able  able  to  control  the 
frequency  and  amplitude  of  each  partial  in  time.  Similarly,  Walsh  synthesis  is 
possible,  using  up  to  16  block  functions.  The  technique  of  additive  synthesis  is 
of  particular  interest,  as  one  can  analyse  and  then  resynthesize  natural  sounds 
according  to  this  paradigm.  This  has  been  shown  to  be  particularly  useful  in 
Grey  (1975),  for  example. 


5. 2. 1.3.  Frequency  Modulation  Mode: 

This  mode  enables  the  hardware  implementation  of  the  F.M.  algorithm, 
developed  digitally  for  sound  synthesis  by  John  Chowning  at  Stanford  University 
(Chowning:  1973).  Using  this  mode,  oscillator[n]  can  be  made  to  frequency 
modulate  oscillator[n+l].  The  user  may  then  control  the  carrier  to  modulation 
(c:m)  ratio  by  simply  controlling  the  frequencies  of  the  two  oscillators.  Simi¬ 
larly,  the  modulating  oscillator  has  a  register  controlling  the  index  of  modula¬ 
tion  to  enable  the  spectra  to  vary  in  time.  We  are  thus  provided  simultaneously 
with  up  to  8  independent  voices  of  F.M.  sound. 


5.2. 1.4.  VOSIM  Mode: 

Recent  work  by  Werner  Kaegi  (Kaegi:  1973,74)  has  shown  the  value  of  a  novel 
synthesis  technique,  capable  of  easily  synthesizing  sounds  as  complex  as 
speech  phonemes.  The  method  involves  outputting  the  function  stored  in  the 
oscillator’s  memory  (a  sine  squared  pulse),  as  a  one  shot.  That  is,  only  one 
cycle  of  the  respective  function  is  output,  the  period  of  which  is  determined  by 
the  frequency  setting  of  the  oscillator.  In  addition,  a  counter  is  provided  to 
control  the  delay  between  subsequent  pulses.  By  a  combination  of  two  oscilla¬ 
tors  working  in  parallel  in  this  mode,  we  are  able  to  utilize  Kaegi’ s  method  to 
synthesize  most  vowel-type  sounds.  By  adding  the  ability  to  introduce  a  degree 
of  random  variation  (the  degree  of  which  is  controllable  over  time),  we  are  also 
able  to  synthesize  consonant  sounds.  (Note  that  the  VOSIM  mode  is  not  yet  fully 
implemented.  This  we  expect  by  the  early  summer,  1978.) 

Perhaps  an  important  point  to  note  is  that  the  use  of  the  various  modes  is  not  mutually 
exclusive.  That  is,  it  is  perfectly  possible  to  be  synthesizing  an  8  partial  tone  using 
bank  mode,  while  we  have  VOSIM,  FM,  and  fixed  waveform  modes  being  utilized  at  the 
same  time.  The  flexibility  of  the  arrangement  is  obvious,  as  is  its  benefit. 
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5.2.2.  Interface  and  Controller 


The  interface  between  the  PDP-ll/45  and  the  synthesizer,  and  the  synthesizer  con¬ 
troller,  were  designed  by  A1  Fogels.  While  most  of  their  details  are  of  only  technical 
interest,  there  are  a  few  features  worth  noting.  First,  the  interface  to  the  PDP-ll/45’s 
UNIBUS  is  as  simple  as  possible;  the  bulk  of  the  logic  resides  on  the  controller  cards 
which  are  connected  to  the  interface  via  a  long  ribbon  cable.  Thus,  any  changes 
required  to  interface  the  device  to  a  non-UNIBUS  system  would  be  minimal.  Secondly, 
the  separation  of  the  interface  and  controller  are  such  that  one  can  not  only  power  the 
synthesizer  up  and  down  without  affecting  the  UNIBUS,  one  could  accidently  cut  the 
connecting  cable  with  no  ill  effect  to  the  UNIBUS. 


5,2,3.  The  Channel  Distributor 

The  channel  distributor  —  designed  by  Guy  Fedorkow  —  has  been  developed  to  meet  a 
long  felt  need  on  the  part  of  composers:  to  control  the  spatial  cheiracteristics  of  a  com¬ 
position.  While  it  might  be  argued  that  such  a  desire  could  be  considered  frivolous,  we 
do  not  concur.  In  essence,  the  justification  for  developing  new  tools  for  musical  compo¬ 
sition  and  performance  is  that  they  expand  the  realm  of  musical  expression.  The 
development  of  a  tool  to  enable  the  efficient  control  of  localization  effects  meets  this 
criterion.  Just  as  counterpoint,  instrumentation  and  voicing  have  traditionally  been 
used  as  means  to  separate  musical  parts,  such  apparatus  would  enable  space  to  be 
utilized  for  the  same  purpose.  That  the  effect  can  be  perceived  and  is  of  musical  merit 
is  obvious  to  anyone  who  has  considered  the  distribution  of  instruments  in  the  seating 
arrangement  of  a  symphony  orchestra.  More  formally,  we  have  scientific  evidence 
which  supports  the  suggestion  that  it  is  easier  to  listen  separately  to  two  complex 
sounds  if  they  occupy  different  positions  in  space,  rather  than  a  common  one  (Koenig, 
1950;  Schubert  and  Schultz,  1962).  We  now  proceed,  therefore,  to  present  a  tool  which 
provides  just  such  control  over  the  angular  cues  of  electroacoustic  music. 

Based  on  the  desire  for  more  powerful  control  and  reduced  physical  bulk,  a  new  sound 
reinforcement  system  has  been  designed.  The  resulting  channel  distributor  is  a  bus 
organized  system  that  controls  the  distribution  of  its  four  audio  input  signals  over  six¬ 
teen  loudspeaker  outputs.  A  prototype  version  of  this  system  (4  channels  of  audio  over 
4  loudspeakers)  is  currently  operational  at  the  University  of  Toronto.  A  brief  list  sum¬ 
marizing  some  of  the  important  aspects  of  the  distributor  is  as  follows: 

1.  The  system  comprises  a  control  unit  and  a  set  of  sixteen  decoder/power 

amplifier/loudspeaker  combinations.  To  increase  modularity,  and  to 
decrease  required  channel  bandwidth,  functions  are  decentralized  wher¬ 
ever  possible, 

2.  All  units  are  "daisy-chained"  together.  That  is,  each  is  connected  only  to  its 

nearest  two  neighbours.  This  connection  consists  of  simply  a  single 
coaxial  cable  for  all  signal  and  control,  and  a  pair  of  wires  for  power  sup¬ 
ply! 

3.  The  distributor  will  accept  four  audio  inputs  and  produce  sixteen 

loudspeaker  outputs.  The  resulting  sixty  four  crosspoints  all  have  pro¬ 
grammable  gain  under  the  control  of  a  central  processor. 

4.  Overall  system  bulk  is  reduced  while  sound  quality  is  improved,  all  as  a  result 

of  the  technique  of  "bi-amping." 
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5.  Good  audio  standards  are  maintained  throughout. 

The  overall  system  architecture,  shown  in  figure  two,  is  like  that  of  a  four  input,  sixteen 
output  mixer,  where  each  output  drives  a  separate  loudspeaker.  However,  the 
system’s  physical  layout,  shown  in  figure  three,  is  clearly  different,  in  that  the  ’mixer’ 
is  distributed  throughout  the  system,  with  a  four  input,  one  output  mixer  in  each 
loudspeaker  location. 

Merely  distributing  the  mixer  makes  a  large  step  towards  the  design  goal  of  reduced 
wiring.  While  each  loudspeaker  now  has  four  inputs,  rather  than  one,  the  inputs  for  all 
loudspeakers  are  the  same.  Thus,  all  loudspeakers  may  be  daisy  chained  onto  the 
same  analog  bus.  This  is  in  contrast  to  the  usual  centralized  mixer,  where  sixteen 
discrete  paths  between  mixer  and  loudspeakers  are  required.  The  addition  of  a  control 
channel  to  adjust  settings  in  each  mixer  loudspeaker  completes  the  system. 

Further  reduction  in  the  amount  of  wire  that  might  be  required  is  made  by  multiplex¬ 
ing  the  four  audio  and  one  control  channel  onto  a  single  high  speed  coaxial  cable.  As  a 
result,  each  loudspeaker  contains  a  remotely  programmed  mixer,  a  power  amplifier, 
and  some  digital  logic  to  recognize  commands  on  the  control  channel.  The  remaining 
functions  of  multiplexing,  timing  and  command  encoding  are  performed  with  the  aid  of 
a  microprocessor  in  the  control  unit. 

Commands  for  the  control  unit  come  from  the  SSSP  synthesizer  in  the  form  of  an 
address  specifying  the  loudspeaker  and  channel  numbers,  followed  by  the  desired 
attenuation  for  that  crosspoint.  Attenuation  is  specified  directly  in  decibels,  in  steps  of 
.75  db.  Six  bits  of  data  yield  over  45  db  of  control  range  at  each  crosspoint.  Because 
the  control  unit  transmits  attenuation  values  to  all  sixty-four  crosspoints  in  a  single 
block  of  data  every  ten  milliseconds,  the  ’soundscape’  may  be  completely  changed  very 
quickly. 

For  stand-alone  use,  a  more  complex  controller  algorithm  is  required.  Software  for 
this  purpose  will  soon  be  completed.  Its  function  is  to  sample  eight  analog  control  vol¬ 
tage  inputs,  arranged  as  an  X  and  a  Y  coordinate  for  each  of  the  four  audio  inputs,  then 
to  calculate  attenuation  values  for  each  of  the  sixty-four  crosspoints,  and  finally,  of 
course,  to  issue  commands  to  each  loudspeaker.  This  will  allow  easy  interface  to  vol¬ 
tage  controlled  synthesizers  or  simply  to  four  joysticks,  allowing  the  musician  to  posi¬ 
tion  four  different  sounds  in  the  listening  area. 

Given  the  limited  computational  power  of  the  microprocessor  in  the  controller, 
loudspeaker  placement  must  be  limited  to  one  or  two  simple  configurations,  based  on  a 
circular  ring  around  the  audience,  or  a  square  grid  suspended  above  the  audience. 
Note  that  in  either  case  all  decoder  and  loudspeaker  boxes  are  identical  and  are 
identified  only  by  a  switch  selectable  address. 

As  mentioned  earlier,  we  have  chosen  to  ’bi-amp’  our  system,  that  is,  to  use  one  or  two 
high  power  central  woofers  with  a  crossover  network  for  each  of  four  input  signals. 
This  results  in  a  significant  reduction  in  power  and  size  for  each  of  the  sixteen  ’main’ 
loudspeakers.  Figure  four  gives  details  of  connections  when  this  crossover  technique  is 
used.  It  should  be  noted  that  crossovers  on  the  inputs  to  the  distributor  restrict  the 
use  of  the  system:  each  of  the  input  channels  must  have  at  least  one  distinct  location 
at  all  times,  because  the  signal’s  low  frequency  components  in  the  woofer  cannot  be 
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turned  off.  However,  in  view  of  the  fact  that  this  system  is  a  distributor  of  finished 
sounds,  and  not  part  of  the  synthesis  process  itself,  we  feel  that  the  reduction  in  cost, 
weight  and  complexity  more  than  compensates  for  the  minor  restriction  in  use. 

In  summary,  it  can  be  seen  that  this  system  attacks  several  problems  of  the  perform¬ 
ing  electronic  musician.  First,  of  course,  it  provides  the  hardware  to  produce  angular 
cues  for  localization  of  sound  in  a  concert  setting.  Furthermore,  it  does  so  with  a 
minimum  number  of  interconnections  on  a  single,  multiplexed  bus.  Decoder/ 
loudspeaker  units  are  all  identical,  and  may  be  connected  in  any  order,  resulting  in  an 
easy  to  install  and  easy  to  maintain  system.  Finally,  the  microprocessor  controller 
allows  the  distributor  to  receive  commands  from  a  wide  variety  of  sources,  ranging 
from  digital  computers  to  analog  control  voltages. 


5.2.4.  The  Collection  Network 

The  collection  network  --  designed  by  Guy  Fedorkow  --  is  essentially  a  computer  con¬ 
trolled  16  channel  to  4  channel  audio  mixer.  The  intention  of  the  device  is  to  enable  a 
composer/performer  to  combine  up  to  16  audio  signals  from  external  sources  (such  as 
microphone)  with  those  generated  by  the  digital  synthesizer.  The  combined  signals 
can  then  be  "spatialized”  by  diffusing  them  over  the  channel  distribution  system  dis¬ 
cussed  above.  Given  that  an  ever  greater  percentage  of  music  being  written  is  for  a 
combination  of  electroacoustic  and  traditional  instruments,  and  given  the  primitive 
state  of  control  offered  by  conventional  mixers,  the  collection  mixer  fufills  a  real  need. 

The  design  of  the  network  has  much  in  common  with  the  distribution  network 
described.  Both  are  distributed  networks  "daisy-chained"  together  in  the  same 
manner.  The  mixer  utilizes  a  minimum  of  cables,  is  small,  and  is  easy  to  install.  As 
well,  it  is  controlled  via  a  micro-processor  which  can  be  shared  by  the  distribution  net¬ 
work.  Finally,  the  collection  network  can  function  "stand-alone"  or  in  combination  with 
either,  or  both  of,  the  synthesizer  and  channel  distributor. 

Functionaly  described,  the  collection  network  consists  of  16  audio  inputs  arranged  in 
four  groups  of  four.  Each  group  of  four  is  housed  in  a  wedge-shaped  monitor  speaker. 
An  important  point  to  make  at  this  stage  is  that  we  consider  providing  aural  feed-back 
to  the  performers  an  integral  part  of  the  collection  process,  we  are  capable  of  giving 
each  group  of  four  a  unique  (personalized)  mix  of  the  4  output  channels;  hence,  the 
monitor  cabinet.  Each  of  the  inputs  has  three  sets  of  controls  which  can  only  be 
accessed  by  the  computer  controller.  These  are:  an  input  attenuator  to  normalize  the 
signal;  a  four  band  equalizer  which  functions  as  a  sophisticated  tone  control;  and  four 
potentiometers,  to  control  the  level  of  the  input  to  each  of  the  four  output  channels, 
respectively.  The  four  channels  output  by  each  input  group  are  then  multiplexed  and 
distributed  throughout  the  network  via  the  "daisy-chain". 

A  prototype  single-station  version  of  the  collection  is  currently  functioning  and 
demonstrable.  We  are  rather  excited  by  the  potential  impact  of  its  concepts.  Both  the 
collection  and  distribution  networks  are  described  in,  "The  Analog  Network  -  A  Struc¬ 
tured  Approach  to  Music  Performance  Systems,"  a  paper  by  Guy  Fedorkow  which  is  in 
final  preparation. 
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5.2.5.  Slider  Input  Control 

One  of  the  major  problems  to  be  dealt  with  in  our  work  is  that  of  man-machine  com¬ 
munication;  proper  system  operation  requires  fast,  intuitive  interaction  between  the 
device  being  controlled  and  the  human  operator.  To  this  end,  a  special  interface  which 
combines  the  intuitive  nature  of  a  lineeir  slide  potentiometer  with  the  flexibility  of  a 
graphics  tablet  was  constructed.  This  we  call  the  "slider  box",  which  was  developed  by 
Guy  Fedorkow.  We  feel  that  this  device  is  a  good  example  of  the  type  of  small  scale 
hardware  development  which  we  would  like  to  further  pursue  in  the  project.  It  is  small, 
inexpensive,  and  has  caused  a  remarkable  improvement  in  the  man-machine  interface 
of  the  system. 

The  slider  (see  figure  five)  is  essentially  a  continuous  plastic  belt  incorporating  a 
motion  detector  [3].  A  thirteen  centimeter  section  of  the  belt  is  exposed  and  can  be 
moved  with  one  finger.  The  direction  and  amount  of  travel  is  digitized  and  may  be  sent 
to  a  computer  via  an  asynchronous  serial  link. 

The  device  may  be  used  with  an  ASCII  terminal  or  a  graphics  tablet,  to  allow  the  user  to 
adjust  the  values  of  variables.  Thus,  in  a  typical  application,  a  parameter  —  e.g., 
volume  or  pitch  —  may  be  selected  with  the  tablet,  and  its  value  adjusted  by  moving  the 
slider.  A  long  upwards  slide  may  therefore  result  in  a  large  increase,  while  a  small 
downwards  slide  will  cause  only  a  small  decrease  in  the  parameter.  The  rate  of  change 
of  the  parameter  can  easily  be  related  to  the  rate  of  movement  of  the  slider. 

In  this  application,  the  slider  has  several  advantages  over  a  normal  slide  potentiome¬ 
ter.  First,  the  slider  is  a  true  motion  sensing  device,  unlike  a  potentiometer,  which  is 
inherently  position  sensitive.  This  makes  it  well  suited  for  updating  parameters  in  an 
interactive  system,  where  a  smooth  transition  between  old  and  new  values  is  impor¬ 
tant. 

A  second  advantage  rests  in  the  fact  that  the  slider  has  no  endpoints.  Therefore,  there 
is  no  initial  position  to  consider,  and  no  hard  limit  on  the  range  of  adjustment  avail¬ 
able.  This  contrasts  with  the  potentiometer  and  A/D  combination,  for  if  the  potentiom¬ 
eter  is  at  the  center  of  its  travel  initially,  the  associated  variable  clearly  cannot  be 
increased  by  mors  than  the  amount  corresponding  to  half  the  travel  of  the  pot.  Also,  it 
is  obvious  that  the  value  could  never  be  changed  by  an  amount  greater  than  the  length 
of  the  pot.  Neither  of  these  problems  arise  with  an  endless  slider. 

A  further  advantage  lies  in  the  slider’s  mechanical  simplicity.  There  is  only  one  moving 
part,  the  belt,  and  its  motion  is  detected  directly  with  two  LED-phototransistor  pairs 
placed  to  respond  to  bars  marked  on  the  surface  of  the  belt. 

The  device  we  constructed  contains  two  sliders  and  tour  general  purpose  momentary 
switches,  and  communicates  with  a  CPU  via  an  RS  232  C  serial  link.  Each  slider  sends 
an  ASCII  character  (an  or  a  ’B’)  for  each  bar  passing  the  detector  in  an  upwards 
direction,  and  a  different  character,  (‘A’  or  ‘C’)  for  a  downward  moving  bar.  Similarly, 
each  switch  sends  a  distinct  character  when  depressed  and  a  different  character  when 


[3]  The  original  concept  of  the  continuous  belt  slider  was  developed  by,  and  is  the  pro¬ 
perty  of:  Allison  Research,  Inc.  2817  Erica  Place,  Nashville, 

Tenn.  37204 
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released.  Finally,  characters  are  also  generated  by  proximity  sensors  when  sliders  are 
either  touched  or  released. 

The  slider  box  is  now  in  general  use  in  the  system  with  excellent  results.  The  device 
could  be  realized  largely  due  to  support  given  by  the  Department  of  Electrical 
Engineering  of  the  University  of  Toronto,  who  subsidized  a  visit  by  Guy  Fedorkow  to  Alli¬ 
son  Research  in  Nashville. 


5.3.  Software 


5.3.1.  Acoustic  SiTnulation 

The  purpose  of  this  work  has  been  to  determine  from  a  musical  and  acoustical  point  of 
view,  the  optimal  configuration  of  the  oscillator  modules  in  the  digital  synthesizer.  The 
importance  of  this  work  is  seen  in  that  the  quality  of  the  sound  available  to  the  com¬ 
poser  is  a  direct  result  of  these  tests.  The  tests  consisted  of  generating  sounds  accord¬ 
ing  to  the  different  models  described  above  for  sound  synthesis.  For  each  model,  vari¬ 
ous  configurations,  speeds,  data  widths,  etc.,  were  tested.  As  a  consequence,  we  were 
able  to  arrive  at  a  useable  design  without  having  to  go  through  several  iterations  of 
building  and  rebuilding  the  synthesizer. 


5.3.2.  Diagnostic  Package 

Once  the  digitad  synthesizer  was  constructed,  an  intensive  period  of  debugging  of  the 
hardware  began.  As  a  matter  of  convenience,  as  well  as  to  protect  the  PDP-11/45  from 
potential  damage,  this  debugging  was  performed  on  a  slave  processor  to  the  11/45,  a 
PDP-ll/lO.  Use  of  this  machine  was  provided  by  the  Department  of  Electrical 
Engineering.  In  order  for  debugging  to  take  place,  diagnostic  software  had  to  be  writ¬ 
ten  which  would  enable  the  engineers  to  access  any  of  the  synthesizer’s  registers  for 
both  reading  and  writing.  This  package,  which  included  communication  software 
between  the  two  computers  as  well  as  to  the  synthesizer,  was  written  by  Bill  Reeves  and 
William’  Buxton. 


5.3.3.  Driver  Software 

Once  the  synthesizer  was  interfaced  to  the  PDP-11/45,  a  driver  routine  had  to  be 
entered  into  the  operating  system  to  enable  it  to  function.  A  key  consideration  in  the 
design  of  this  module  was  the  fact  that  the  device  had  to  run  in  real-time  on  a  time¬ 
sharing  system.  The  power  of  the  UNIX  operating  system,  in  combination  with  our 
experience  with  real-time  animation  helped  in  this  a  great  deal.  The  driver  which 
resulted  was  written  by  Greg  Hill  and  Bill  Reeves.  It  is  interrupt  driven,  where  the  rate 
of  interrupt  (and  therefore  update  cycle)  is  set  by  the  crystal  controlling  the  timing  in 
the  synthesizer  controller. 
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5.3.4.  Data  Structures  and  Interfaces 


Even  the  power  of  UNIX  could  not  prevent  this  aspect  of  the  design  from  being  a  night¬ 
mare.  Before  any  user  or  performer  software  could  be  written,  suitable  data  struc¬ 
tures  and  protocols  for  communication  had  to  be  defined.  These  include  the  internal 
representation  of  scores,  notes,  objects,  functions,  etc.  This  work  was  undertaken  by 
Bill  Reeves  and  William  Buxton.  This  aspect  of  design,  in  particular,  will  have  a  strong 
influence  on  the  eventual  success  of  the  system.  As  a  result,  whenever  a  decision  was 
being  made  which  had  direct  musical  implications,  we  would  have  an  in-depth  discus¬ 
sion  with  the  musical  experts  affiliated  with  the  group.  While  it  took  a  considerable 
effort,  this  aspect  of  design  seems  --  so  far  --  to  have  met  with  success.  It  was  at  this 
stage  of  development  that  we  were  able  to  finaly  formalize  our  notions  of  musical 
hierarchy,  and  to  design  data  structures  which  would  allow  the  composer  to  construct 
his  own  "deep  structures". 


5.3.5.  Perform  Program 

An  initial  version  of  a  perform  program  is  now  operational.  This  program  will  perform 
“  in  real-time  —  scores  which  have  up  to  16  simultaneous  notes.  While  our  data- 
structures  allow  for  scores  to  be  represented  as  tree  structures,  for  this  version  of  the 
program  to  function  the  scores  must  first  be  pre-sorted  into  a  linear  linked  list  of  note 
structures.  Nevertheless,  the  program  enables  both  the  testing  and  use  of  the  system 
even  at  this  early  stage.  This  program  was  written  by  Rob  Pike  and  Bill  Reeves. 


b. '3)3.  Function  Editor 

Since  many  parameters  in  the  system  will  be  controllable  by  functions  operating  over 
time,  a  function  editor  was  deemed  necessary.  This  is  an  editor  which  would  enable  the 
composer  to  easily  define,  store,  and  modify  functions  over  time  (such  as  envelopes, 
glissandi,  etc.).  The  functions  so  defined  can  then  be  used  by  other  modules  in  the  sys¬ 
tem.  This  editor  has  been  written  by  Buxton  and  is  currently  part  of  the  system. 


5.3.7.  Object  Editors 

The  role  of  the  object  editor  was  described  in  section  4.3  of  this  proposal.  We  currently 
have  operational  an  editor  which  enables  objects  to  be  defined,  tested,  modified,  etc., 
in  either  fixed  waveform  or  frequency  modulation  modes.  This  package  was  written  by 
Buxton.  In  addition,  graduate  students  have  implemented  two  different  approaches  to 
the  VOSIM  mode.  This  work  shows  great  promise  as  a  first  attempt  to  enable  sound 
specification  in  terms  closer  to  the  perceptual  as  opposed  to  the  acoustical  domain. 
An  editor  which  enables  sound  specification  using  bank  mode  (additive  synthesis)  is  in 
the  final  design  stages  and  should  be  implemented  in  the  near  future. 
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5.3.8.  Score  Editors 


This  aspect  of  the  software  is  still  at  a  rather  primitive  stage.  There  currently  exists  a 
program  which  enables  diatonic  scores  to  be  defined  alpha-numeric  ally.  In  addition 
there  exists  a  graphics  program  using  a  small  sub-set  of  common  music  notation;  how¬ 
ever,  the  score  editor  is  one  of  the  most  important  and  complex  pieces  of  software  in 
the  system.  ViTe  are  therefore  taking  considerable  time  and  effort  with  its  design. 


5.3.9.  Distribution  N etwork 

The  distribution  and  collection  network  software  is  of  a  somewhat  lower  priority  than, 
for  example,  the  score  editor.  Nevertheless,  a  student  of  Prof.  Baecker’s,  Ivor  Ladd, 
has  implemented  a  prototype  graphics  controlled  system  called  "MUSICDANCER."  This 
system  demonstrates  a  well  planned  control  structure  which  will  serve  as  a  prototype 
for  our  first  operating  system. 


5.3.10.  Collection  Network 

Two  pairs  of  students  in  Prof.  Baecker’s  graduate  graphics  course  have  implemented 
prototype  software  for  the  collection  network.  One  of  the  luxuries  of  having  the 
resources  of  this  class  was  that  we  were  able  --  through  the  use  of  different  groups  —  to 
implement  various  approaches  to  the  same  problem  in  order  to  compare  results.  This 
has  proven  both  useful  and  informative.  The  fact  that  much  of  the  resulting  software 
will  be  useable  in  production  is  an  added  benefit. 


5.4.  Miscellaneous  Contacts  and  Presentations 

During  the  course  of  the  past  year  several  contacts  have  been  made  which  have 
significantly  contributed  to  the  collection  and  dissemination  of  information  concerning 
the  project.  This  has  been  largely  the  result  of  visits  to  and  from  other  scholars  active 
in  the  field,  as  well  as  the  attendance  of  related  academic  conferences.  This  activity 
will  be  summarized  in  this  section. 

During  the  course  of  the  year,  Buxton  was  able  to  visit  Bell  Telephone  Laboratories  at 
Murray  Hill,  New  Jersey,  Dartmouth  College,  Hanover,  New  Hampshire,  The  Center  for 
Music  Experiment  at  UCSD,  the  Center  for  Computer  Research  in  Music  and  Acoustics 
at  Stanford  University,  and  the  Learning  Research  Group  at  the  XEROX  Research 
Center,  Palo  Alto.  The  visit  to  UCSD  coincided  with  the  Second  International  Confer¬ 
ence  on  Music  and  Computation  which  was  also  attended  by  Ciamaga  and  Patrick.  In 
addition,  Fedorkow  visited  Allison  Research  in  Nashville.  The  prime  benefit  of  this  trip 
has  been  the  slider  box,  described  in  section  5.2.5  of  this  document. 

Members  of  the  project  took  part  in  two  other  professional  meetings.  First,  Sasaki  and 
Buxton,  participated  in  the  Journees  d’Etude  des  Musiques  Electroacoustiques  at 
Bourges  France,  May  1977.  At  this  meeting  Buxton  presented  the  paper,  "A  Computer 
Controlled  Sound  Distribution  System  for  the  Performance  of  Electroacoustic  Music," 
which  was  written  by  Fedorkow,  Buxton  and  Smith.  This  paper  included  a  demonstra¬ 
tion  of  a  prototype  version  of  the  channel  distributor,  which  was  controlled  by  a  micro- 
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processor.  Sasaki  also  presented  a  paper  and  demonstrated  the  analogue  synthesizer 
which  he  developed  as  part  of  the  research  for  his  doctoral  studies.  Finally,  Buxton 
presented  an  invited  paper,  "Towards  a  Computer  Based  System  for  Music  Composition 
and  Performance,"  at  the  ACM/SIGLASH  Conference,  NYU  New  York,  in  October. 

In  addition  to  the  above,  the  project  has  received  visits  from  several  researchers  active 
in  related  fields.  These  include  the  well  known  composer  and  theorist  Iannis  Xenakis 
and  Dr.  Otto  Laske  (who  spent  a  week  with  us  as  a  distingushed  visitor).  Professors  Ist- 
van  Anhalt  (of  Queen’s  University),  Peter  Clements  (of  the  University  of  Western 
Ontario),  and  Barry  Truax  (of  Simon  Fraser  University)  have  all  visited  the  project.  One 
of  the  consequences  of  these  visits  is  that  Prof.  Clements  will  be  spending  time  working 
at  our  facility  during  the  summer  of  1978.  In  addition,  we  should  point  out  our  close 
contact  with  Prof.  Truax,  whose  knowledge  of  the  field  has  made  a  great  contribution  to 
our  work.  Finally,  Ken  Pulfer  of  NRC  spent  a  day  visiting  the  site.  As  his  system  at  NRC 
(Pulfer,  1970)  has  had  a  very  strong  influence  on  our  approach,  this  was  also  a  stimu¬ 
lating  meeting. 

Ciamaga,  Buxton,  and  Patrick  are  currently  involved  with  a  project  in  computer  music 
being  sponsored  by  the  Canadian  Commission  for  Unesco.  This  is  Project  14  of  the 
Joint  European  Studies,  which  has  derived  from  the  Helsinki  agreement.  One  of  the 
key  aims  of  this  project  is  to  increase  the  accessibiliy  of  information  in  the  field. 
Towards  this  end,  the  project  is  sponsoring  two  sets  of  workshops  and  a  conference  in 
August  1978.  As  a  result,  the  SSSP  will  be  hosting  two  one  week  workshops  for  com¬ 
posers  during  the  period  of  August  14  -  28,  1978.  These  workshops  --  which  run  con¬ 
currently  with  others  at  other  institutions  —  will  be  followed  by  a  conference  to  be  held 
at  the  University  of  Arhus,  Denmark.  Ciamaga,  Patrick  and  Buxton  are  ail  involved  in 
the  planning.  Along  the  same  lines,  Buxton  has  been  invited  to  conduct  a  composer’s 
workshop  on  computer  music  as  part  of  the  International  Society  for  Contemporary 
Music  (ISCM)  World  Music  Days,  Stockholm,  Sweden,  in  May  1978.  We  see  these  projects 
as  excellent  opportunities  to  make  contact  with  foreign  composers,  as  well  as  exercise 
a  degree  of  international  exchange  of  knowledge. 

Besides  members  of  the  academic  community,  the  project  is  affecting  segments  of  the 
public  in  two  ways.  First,  as  a  result  of  the  trip  to  Bourges,  we  have  been  able  to 
present  a  series  of  informal  concert/presentations  of  an  international  selection  of  tape 
music.  This  we  are  doing  as  a  series  of  seven  monthly  concerts,  where  the  pieces  are 
chosen  from  the  international  repertoire.  We  see  these  concerts  as  an  important 
means  of  affecting  the  local  music  community  and  stimulating  interest  of  composers  in 
our  project.  Finally,  the  Canadian  Broadcasting  Corporation  is  currently  filming  a  six 
part  television  series  on  the  history  of  music.  This  series,  to  be  shown  internationally, 
is  hosted  by  the  violinist  Yehudi  Menuhin.  In  this  series,  a  portion  of  the  time  will  be 
devoted  to  computer  music.  Since  the  SSSP  was  chosen  as  the  site  to  be  presented,  it 
appears  that  we  will  contact  a  greater  number  of  people  with  our  work  than  we  antici¬ 
pated. 
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5.5.  Publications 


Although  the  project  was  initiated  only  a  year  ago,  two  publications  have  already 
resulted,  while  others  are  in  preparation.  Buxton  (1977a)  is  a  detailed  survey  of  the 
literature,  while  Buxton  (1977b)  is  a  directory  to  research  in  the  field  throughout  the 
world.  The  second  publication  was  financed  and  published  by  the  Canadian  Commission 
for  Unesco. 

Due  to  the  amount  of  documentation  which  is  being  generated  by  the  project,  and  due 
to  the  interest  shown  in  it  by  other  institutions,  we  have  initiated  a  series  of  technical 
memos  which  will  facilitate  the  quick  and  inexpensive  dissemination  of  our  work.  First 
among  these  (currently  in  preparation)  are; 

Fedorkow,  G.  "The  Analog  Network  -  A  Structured  Approach  to 
Music  Performance  Systems" 

Fedorkow,  G.,  Buxton,  W.  and  Smith,  K.C.  "A  Computer  Controlled 
Sound  Distibution  System  For  the  Performance  of 
Electroacoustic  Music" 

Buxton,  W.  "Towards  a  Computer  Based  System  for  Music  Composition 
and  Performance" 

Laske,  0.  "System  Structure  and  Human  Memory:  the  Relevance 
of  Understanding  User  Behavior  in  Interactive  Musical 
Task  Environments" 

The  last  mentioned  paper  is  the  text  of  a  seminar  given  by  Dr.  Laske  while  he  was  a 
guest  of  the  project  for  a  week  in  November.  This  visit  was  financed  by  the  Departmant 
of  Computer  Science  under  a  program  for  bringing  distinguished  scholars  to  the 
Department. 


6.  Schedule  of  Work  to  be  Done 

The  overall  time-scale  proposed  for  the  work  described  is  eighteen  months.  While  the 
research  proposed  is  by  nature  open-ended,  it  is  felt  that  significant  results  can  be 
demonstrated  in  this  time.  As  we  can  assume  that  by  the  start  of  the  new  grant  period 
the  synthesizer  will  be  completed,  the  bulk  of  our  effort  will  concentrate  on  the 
theoretical  and  software  aspects  of  the  project. 

In  terms  of  software,  our  main  concern  is  to  get  a  workable  score  editor  up  and  run¬ 
ning.  We  feel  that  this,  with  the  associated  perform  pro^am  could  take  until  at  least 
Christmas  1978  to  implement  in  a  satisfactory  version.  A  workable  version  of  the 
object  editors  should  be  functioning  by  the  start  of  the  summer,  to  enable  us  to  con¬ 
centrate  on  the  score  editor.  We  have  requested  funds  to  support  one  undergraduate 
throughout  the  grant  period,  and  another  one  during  the  two  summer  months  of  1978 
and  the  full  summer  of  1979.  The  student  employed  during  the  summer  only  would  be 
given  a  specific  piece  of  software  to  work  on.  W’^e  anticipate  that  in  1978  that  would  be 
the  distribution  editor.  In  1979  it  is  expected  that  we  will  have  gained  sufficent 
insights  into  the  problem  and  past  mistakes  that  a  large  amount  of  revision  will  be 
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required.  This  would  be  the  role  of  the  student  during  that  summer. 

The  student  working  throughout  the  project  would  work  closely  with  Buxton.  His  func¬ 
tion  would  be  to  concentrate  more  on  problems  of  implementation,  while  Buxton’s 
main  role  is  interaction  with  the  users,  the  investigators,  and  the  system.  Since  the 
method  of  research  involves  constant  revision  of  the  system,  this  must  be  undertaken 
with  careful  consideration,  so  as  not  to  overly  traumatize  the  users  by  an  unstable  sys¬ 
tem. 

In  summary,  we  feel  that  by  early  1979  we  will  have  a  reasonably  comprehensive  sys¬ 
tem  in  operation.  That  will  leave  one  full  year  in  the  grant  period  to  study  how  com¬ 
posers  react  to  the  system,  observe  their  behavior,  analyse  the  results,  and  then 
attempt  to  bring  the  benefits  of  that  analysis  back  into  the  system. 
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Figure  1:  Functional  Block  Diagram  of  SSSP  Hardware. 
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Output  Distributor,  Logical  Organization 
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Figure  Four, 

Output  Distributor  with  Common  Bass  Channel 
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Figure  Three# 

Output  Distributor,  Physical  Layout 
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Kenneth  C.  Sevcik,  June  l^'^I 

[Proceedings  of  the  Symposium  on  Computer-Communication, 
Networks  and  Teletraffic,  Polytechnic  Institute  of 
Brooklyn,  1972] 
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CSPG-20  A  STUDY  Or  LANGUAGE  DIRECTED  COMPUTER  DESIGN 
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E.  Lochovsky  and  D.  Tsichritzis,  May  1974  [  INEOF , 
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[M.Sc.  Thesis,  DCS,  1974] 

CSRG-47  LANGU;^GF  DESIGN  TO  ENHANCE  PROGRAMMING  RELIABILITY 
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*  CSPG-68  A  SYNTHETIC  ENGLISH  QUEPY  LANGUAGE  FOR  A 
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April  1976 
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D.  Barnard  and  D.  Thompson  (Eds.),  Fourth  Edition,  May  1976 
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CSPG-71  OPTIMIZATION  FEATURES  FOE  THE  ARCHITECTURE  OF  A 
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CSRG-83  topics  IN  QUEUEING  NETWORK  MODELING 
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Edward  Yarwood,  September  1977  [M.Sc.  Thesis,  DCS,  197U] 
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[M.Sc.  Thesis,  DCS,  1977] 

CSPG-87  «OLGA'  LANGUAGE  REFERENCE  M?^.MUAL 
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CSFG-88  USING  A  GRAMMATICAL  FORMALISM  AS  A  PROGRAMMING  LANGUAGE 
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Frederick  H.  Lochovsky,  April  1978 
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AN  INTRODUCTION" 
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